PLUGINAPI-208/209 Add MQR severity and issue-count metrics to CoreMetrics

[JoniDutoit]

What

Two related additions to org.sonar.api.measures.CoreMetrics, both part of the SC-53446 (Deprecate Standard metrics and promote MQR-related metrics) effort:

PLUGINAPI-208 - severity metrics for overall code (MQR mode)

CoreMetrics had already declared the new-code-period severity metrics (new_reliability_issue_severity, new_security_issue_severity, new_maintainability_issue_severity). This adds the overall-code equivalents.

PLUGINAPI-209 - flat issue count metrics

SQC needs flat count metrics equivalent to SQS's software_quality_*_issues so that:

• Deprecated standard metrics (bugs, new_bugs, vulnerabilities, new_vulnerabilities, code_smells, new_code_smells) can be replaced on the measures page and in project badges
• The new metrics can be used as Quality Gate conditions
• SQC and SQS implementations stay aligned, reducing divergence

These flat count metrics currently exist in a dedicated class in SQS, SoftwareQualitiesMetrics (not in CoreMetrics), and SQC does not compute them. Moving them to CoreMetrics follows the established convention and lets both products share the same declaration.

What's in this PR

New 9 metrics definitions in CoreMetrics:

• 3 severity metrics (overall code): RELIABILITY_ISSUE_SEVERITY, SECURITY_ISSUE_SEVERITY, MAINTAINABILITY_ISSUE_SEVERITY
• 6 issue-count metrics: SOFTWARE_QUALITY_{MAINTAINABILITY,RELIABILITY,SECURITY}_ISSUES and their NEW_* variants

This is the lowest-level, most-blocking change: the report processor analysis and sonarcloud-core measures formulas need these metrics to exist before they can compute them.

The issue-count metrics mirror SQS's SoftwareQualitiesMetrics class exactly (value type, direction, best value, qualitative flags). The severity metrics mirror the existing NEW_*_ISSUE_SEVERITY metrics' shape (value type, direction, best/worst value on the 0-25 SeverityValues scale).

Metrics are auto-registered from CoreMetrics by reflection at server startup (RegisterMetrics).

Sequencing (this PR blocks the rest)

1. This PR — declare metrics in CoreMetrics (plugin-api)
2. Report processor — compute the metrics during analysis.
3. sonarcloud-core — measures formulas to aggregate values for new/overall code
4. SQC frontend — measures page + project badges switch from deprecated standard metrics to these
5. Quality Gate — allow these as conditions

Notes

• Issue-count metrics: setQualitative(false) on the 3 overall-code metrics, true on the 3 new_* variants — intentionally mirrors SQS's SoftwareQualitiesMetrics as-is, not an inconsistency.
• @since 13.10 matches the current gradle.properties version (13.10-SNAPSHOT) and the CHANGELOG.md entries added under ## 13.10.

Validation

• Local compile verified
• CHANGELOG.md updated under ## 13.10, two entries (severity metrics, issue-count metrics)

[hashicorp-vault-sonar-prod]

PLUGINAPI-209

PLUGINAPI-208

[anita-stanisz-sonarsource]

LGTM!

[dorian-burihabwa-sonarsource]

Will continue the review later. Some issues might already be addressed ahead of final review

[gitar-bot]

CI failed: 1 infrastructure failure caused by a temporary network/download error when fetching a dependent GitHub action archive.

Overview

1 log analyzed across 1 unique error template. The failure was entirely infrastructure-related due to a failure in downloading a GitHub action archive.

Failures

Action Archive Download Failure (confidence: high)

• Type: infrastructure
• Affected jobs: 94709955644
• Related to change: no
• Root cause: The CI runner encountered a temporary network or GitHub codeload failure while attempting to download the action archive 'gradle/actions', causing workflow setup to fail.
• Suggested fix: Re-run the failed GitHub Actions workflow job to retry downloading the action archive.

Summary

• Change-related failures: 0
• Infrastructure/flaky failures: 1 (GitHub action archive download error)
• Recommended action: Re-run the CI workflow to clear the transient infrastructure failure.

Code Review ✅ Approved 1 resolved / 1 findings

Adds 9 new MQR severity and flat issue-count metric definitions to CoreMetrics with corresponding test coverage. No issues found.

✅ 1 resolved

✅ Bug: NEW_* software-quality issue metrics still qualitative(true)

📄 plugin-api/src/main/java/org/sonar/api/measures/CoreMetrics.java:1620 📄 plugin-api/src/main/java/org/sonar/api/measures/CoreMetrics.java:1736 📄 plugin-api/src/main/java/org/sonar/api/measures/CoreMetrics.java:1851
The overall-code count metrics SOFTWARE_QUALITY_MAINTAINABILITY_ISSUES, _RELIABILITY_ISSUES and _SECURITY_ISSUES were switched to setQualitative(false), reflecting that these are now flat issue counts rather than qualitative measures. However, the corresponding new-code metrics NEW_SOFTWARE_QUALITY_MAINTAINABILITY_ISSUES (line 1620), NEW_SOFTWARE_QUALITY_RELIABILITY_ISSUES (line 1736) and NEW_SOFTWARE_QUALITY_SECURITY_ISSUES (line 1851) were left at setQualitative(true). This makes the new/overall pairs inconsistent (they are the same kind of flat count) and likely causes the new-code counts to be rendered/colored as qualitative in the UI. Unless intentional, set these three new-code metrics to setQualitative(false) to match their overall-code counterparts.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[dorian-burihabwa-sonarsource]

LGTM 👍

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Adds 9 new MQR severity and flat issue-count metric definitions to CoreMetrics with corresponding test coverage. No issues found.

✅ 1 resolved

✅ Bug: NEW_* software-quality issue metrics still qualitative(true)

📄 plugin-api/src/main/java/org/sonar/api/measures/CoreMetrics.java:1620 📄 plugin-api/src/main/java/org/sonar/api/measures/CoreMetrics.java:1736 📄 plugin-api/src/main/java/org/sonar/api/measures/CoreMetrics.java:1851
The overall-code count metrics SOFTWARE_QUALITY_MAINTAINABILITY_ISSUES, _RELIABILITY_ISSUES and _SECURITY_ISSUES were switched to setQualitative(false), reflecting that these are now flat issue counts rather than qualitative measures. However, the corresponding new-code metrics NEW_SOFTWARE_QUALITY_MAINTAINABILITY_ISSUES (line 1620), NEW_SOFTWARE_QUALITY_RELIABILITY_ISSUES (line 1736) and NEW_SOFTWARE_QUALITY_SECURITY_ISSUES (line 1851) were left at setQualitative(true). This makes the new/overall pairs inconsistent (they are the same kind of flat count) and likely causes the new-code counts to be rendered/colored as qualitative in the UI. Unless intentional, set these three new-code metrics to setQualitative(false) to match their overall-code counterparts.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}