Question about Quality Gate for PR's

SonarQube
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    Enterprise 8.3.1
  • what are you trying to achieve
    Pull Request decoration in Azure
  • what have you tried so far to achieve this
    Setup the service connection and set the quality gate as a status check on the main branch policy

The problem is that the given quality gates we have set only fail the build when we build the feature branch, but when the PR builds the same branch it passes.

PR

image
image1222×773 34.5 KB

Branch

image
image1300×704 32.5 KB

Conditions

image
image994×814 19.6 KB

Azure PR
image

Is there something we are missing that makes the PR pass the quality gate even though we have the bugs and blockers thresholds set to a lower value?

2

Hi @dwal,

If you check your Quality Gate criteria, you’ll see that you have only the Code Coverage on the New Code.
All the other criteria are set on the Overall Code.

That being said, look at the Branch and PR analysis:
PR is Passed. Normal: the PR is only New Code and Coverage is 0% (and match your QG criteria)
Branch is Failed and the reasons are: “on Overall Code, 350 Blocker issues and 386 bugs”.

You should modify your Quality Gate criteria to include more criteria on the New Code (which will block then the PR), as your New Code is the one including the 350 New Bugs etc.
Check the QG “built-in” in SonarQube, that we offer at first. This one includes the most important criteria we find relevant to analyse your source code. You can then copy and create your own Quality Gate, according to your QA expectations.

The concept behind is “Clean As You Code”.
You should rather focus on having a super clean and safe new code than on the Overall Code which could have an important technical debt, due to past devs.

Hope this helps,
Carine

3

Thanks for the quick reply, we will have a look at the new code quality gate configuration. I think that we need to have some more relaxed rules on the overall code (since it is a code base with a long history), but can then according to your suggestion have stricter rules on new code to avoid introducing new problems while we try to fix the existing issues.

I assume it is possible to allow for the overall to be “messy” and have higher thresholds and to set all the new code as more strict. Or might that be problematic if one tries to edit some method in an existing class that has a lot of old bugs, as in that it will count the old bugs that are present in the class when adding a new method?