SonarQube has a feature that ignores the quality gate metrics for coverage and duplications when the number of new code lines is less than 20. This applies in short-lived branches as well as long-lived ones. The work for this appears to be captured in this ticket, which is the only place I found this feature to be documented (I searched through our instance’s official docs but apologize if I missed it). As a quality champion I disagree with the need for this feature based on the use cases in that ticket, but I digress.
Unfortunately we have run into a less-than-ideal scenario where our short-lived branches have a passing quality gate despite insufficient coverage, but when merged to the parent long-lived branch which has more than 20 lines of code, it fails the previously passing quality gate and fails the build, which breaks our CI. This is obviously not ideal, as it then requires remediation by a developer after the merge to the long-lived branch, which defeats the purpose of trying to gate at the short-lived branch level.
Short-lived branch, quality gate passed, and build passed, so PR was approved and merged:
After merging to the long-lived branch, the quality gate failed (it was passing before), which failed the build:
Is it possible to disable this feature, i.e., force SonarQube to gate on all metrics regardless of the number of new code lines?
Ideally developers shouldn’t need to know the nuances of how SonarQube functions in order to use it effectively. Unfortunately, our version of SonarQube doesn’t support pull request annotation for our source control provider (Bitbucket Cloud). As a result, for feedback mechanisms we rely on custom-built integrations that both comment on the PR and the TeamCity build with the quality gate status (the build fails in the case of a failing quality gate).
We are using SonarQube Enterprise 7.9.5 LTS and the .NET Core global tool version of SonarScanner for MSBuild 4.10.0 for this project in question.