Bitbucket/Teamcity/Sonarqube : Quality gates reset to green after any commit/build for PR

SonarQube Server / Community Build
, ,
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    Sonarqube Enterprise, server version 7.3.0.15553
    Teamcity Sonarqube Scanner version: <Default (2.4)>

  • what are you trying to achieve
    PRs for feature branches should be blocked if any commits break quality gates. These quality gates are currently reset to green by any empty commit, or re-build.

  • what have you tried so far to achieve this
    tried changing Leak Period to 100 days in the past
    tried changing Leak Period to BASELINE, ‘BASELINE’
    tried changing Teamcity SonarQube runner parameter Project version from our internal build identifier to the teamcity build #

Sonarqube config:
Quality gates: default (Sonar way)
Leak period: default (previous_version)

Reproduction steps:
be on main branch
git checkout -b new_feature_branch
edit some file, adding lint errors
git add .
git commit -m “commit will break linter”
git push origin new_feature_branch

now, a build will be triggered, which will invoke the SonarQube Runner. The Runner will correctly identify the lint error, and set Quality Gate to RED. In the Bitbucket PR, this is displayed correctly, and the user may not merge their code

Now, say the user creates and pushes an empty commit, or even re-runs the above build. We see that the sonarqube runner is re-invoked, but now the quality gate is switched to green! This is despite the runner identifying the same existing lint issues.

I believe this is a problem with our Leak Period setting, but the Sonarqube documentation does not discuss how to set this field to support feature branches. IE, an entire feature branch (all of it’s accumulated changes) should be considered the new-code-period, and diffed against the base branch. What is the best way to achieve this?

Thanks for your help!

2

Hi,

Welcome to the community!

SonarQube 7.3 is well past EOL. You should upgrade immediately. Your upgrade path is:

7.3 → 7.9.5 (current LTS) → 8.6.1 (current version; optional)

If you still have a problem after upgrading, please come back to us.

 
Ann

3

Ann,

OK that makes sense as a first step. I’ve created a ticket in our system to get the upgrade done ASAP, but it will likely be in 2021Q2 as we have a large number of projects dependent on SonarQube.

Shall we archive this ticket for now? I’ve linked it in our ticket for upgrading, so I can update here if the upgrade resolves our issues.

Thanks for your prompt response!
Sam

1 Like