Possible to enforce all quality gate metrics on branches with less than 20 code lines?


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. :slight_smile:

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.

Thank you!

This is a problem I’ve run into, and had to deal with in our build process, outside of SonarQube.

Ideally, what you really want is for the quality gate to be able to check coverage “after merge”. That isn’t actually an available choice in SonarQube. I frankly am not interested in the coverage of new code. It’s an interesting number, but it’s almost impossible to put any intelligence or rules around it. I am ONLY interested in the “after merge” value.

Despite the fact that the quality gate can’t check for this, the metric is available through the REST api. I implemented this by writing code in our Jenkins pipeline script that simply retrieves the required quality gate numbers, along with the resulting “after merge” coverage, and if the resulting value is in violation, it fails the build with a message. The same code also checks the resulting duplication percentage.

We’re on v7.9.2.


You’re looking for this ticket:

SONAR-10485 - Provide a way to configure the Quality Gate fudge factor

which we anticipate handling for the new LTS, E.T.A early May.


This is great news, thank you for the info!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.