PR Decoration should display the actual metrics used in the Quality Gate (e.g. `new_line_coverage` i

Suggest new features
,
1

Summary

The PR decoration comment posted by the SonarCloud bot displays hardcoded metrics (new_coverage, new_duplicated_lines_density) regardless of which metrics are actually configured as conditions in the project’s Quality Gate. This creates confusion and undermines trust in the Quality Gate result.

Concrete example

Our Quality Gate condition is new_line_coverage < 80% → fail.

The PR comment shows: 68.6% Coverage on New Code with a green checkmark (Quality Gate passed).

This is technically correct — new_line_coverage is e.g. 82%, so the gate passes — but the displayed new_coverage (the weighted line + branch coverage metric) is 68.6%, which looks like a failure to anyone reading the PR.

Developers reading the comment reasonably conclude one of:

  • The Quality Gate is broken
  • The 80% threshold isn’t being enforced
  • The number shown is the one that was checked (it isn’t)

None of these are true, but the comment provides no way to tell. The actually-checked metric (new_line_coverage) is not shown anywhere in the PR decoration.

Requested change

The “Measures” block in the PR decoration comment should display the metrics that are actually configured as conditions in the project’s Quality Gate — not a fixed list.

If the Quality Gate checks new_line_coverage, show Line Coverage on New Code. If it checks new_coverage, show Coverage on New Code. Same logic for duplication (new_duplicated_lines_density vs new_duplicated_lines), and any other metric pair where SonarCloud offers both a combined and a specific variant.

This would make the PR comment a faithful representation of the Quality Gate evaluation, instead of a parallel view that may contradict it.

Why this matters

  • Trust: Developers, reviewers, and auditors should be able to read the PR comment and understand why the gate passed or failed. Today they cannot.
  • Compliance / ISO 27001 context: For organisations using SonarCloud as evidence in quality and security audits (ISO 9001, ISO 27001 A.8.28, A.8.29), the PR decoration is often the primary visible artifact. A mismatch between displayed metrics and gate logic is an audit finding waiting to happen.
  • Onboarding: New developers consistently misread the comment. Every team that uses new_line_coverage instead of new_coverage has to document the discrepancy internally, which is exactly the kind of friction tooling should eliminate.

Workaround today

Either switch the Quality Gate to use new_coverage (changes the semantics of the threshold), or maintain internal documentation explaining the mismatch (ongoing maintenance cost, doesn’t scale across teams).

Neither is satisfactory. The correct fix is in the product.

Scope

This applies to PR decoration on GitHub, GitLab, Azure DevOps, and Bitbucket — same hardcoded behaviour across all integrations as far as we can tell.