For context, my team is using SonarQube 7.7 Enterprise Edition.
The native quality gate metrics in SonarQube (coverage, duplicated lines, maintainability, reliability, and security) all have options for assessment on only “new code,” which my team applies to our quality gate to flag changes on short-lived branches that will introduce issues if merged upstream. Our CI pipeline generates a variety of issue reports (e.g. Fortify, bandit, and dependency check) that SonarQube ingests fine, but many of them are considered for the entire code base and not just for new code.
When our developers work on a feature branch and review findings in SonarQube, they’re currently seeing dependency warnings and security issues from bandit/Fortify that they did not introduce in their short-lived feature branch, but were instead pre-existing in the application (and have not yet been dealt with). This results in the quality gate for their feature branch failing, when really it should pass because the new code they are proposing is not introducing the noted security/dependency issues.
We’re looking for a way to let SonarQube ingest all the reports it currently supports, but to have it only flag issues on short-lived branches if they were introduced in the new code on that branch. Since SonarQube has knowledge about the branch and the merge target, it knows which lines are new and can do the cross-check to see whether an issue flagged by, for example, Fortify on a particular line is something that was newly-introduced in the developer’s short-lived feature branch.
Using the Fortify plugin as an example, we currently ingest our low/medium/high/critical issues into SonarQube and have set metrics for each issue level in our quality gate. These metrics, however, do not apply to new code, and as such cannot fail the quality gate of a short-lived branch. Once a developer’s short-lived feature branch has been merged into a long-lived branch the metrics are applied and the quality gate can then fail based on the number of reported Fortify issues. We would like to catch newly-introduced issues before they’re merged, when the developer is still working on the functionality of the feature branch.
Based on my quick skim over both the Fortify plugin and SonarQube source, it looks like the “…on New Code” Metric instances returned from Metric.Builder() must be handled specially by the SonarQube branch analysis code…?
Is it possible to somehow register a metric with SonarQube such that it behaves the way the “…on New Code” native metrics do, where a failure in the metric will show up as a failed quality gate on the short-lived branch’s dashboard?