We’ve been having a similar issue to this. We’re on Community Edition Version 8.9 (build 43852).
Some of our builds are passing the new code quality gate but there are clearly new sonar issues found (this can be verified by going to Overview->Overall Code->Code smells->Creation Date->(set date to cover past week)).
I would like to check if this is a known issue or if we’re doing something wrong in our quality gate. Our gate looks like this (and I am certain that it is being run):
By analysis do you mean our rules? Here they are:
I’m not sure I’m allowed to post analysis results, but even when we have 0 new code smells after a build, we sometimes still get additional code smells on the overall code tab.
Hi,
By analysis, I mean the homepage of your project, with both tabs : New Code and Overall Code metrics.
To answer your last post "“even when we have 0 new code smells after a build, we sometimes still get additional code smells on the overall code tab” : Your Quality Gate is quite “strange” with value for Overall Code that I don’t really get :
Why should the QG fail when you have “more than 43 800 Code smells”? Why don’t you put here a metric rating directly ? (Maintainability rating for example)
Instead of putting numbers/values here, it’s better to stick to rating, which are here especially to let you manage the quality and the security of your source code.
Carine
We didn’t have those overall code metrics conditions before, we added them to make sure we don’t get more defects that what we already had when SonarQube started passing quality gates even though there were issues found in new code. This started happening about 3-4 months ago.
Now we have to manually check the Overall code tab to see if there are new issues even though the SQ gate says it passed.
If you want to be sure that your new code is as clean as possible, I’d encourage you to setup your Quality Gate in that sense, like in the “Built-in” QG you have, especially having Ratings at A, and setup your New Code period correctly as well (previous version of your project for example).
The philosophy of SonarQube is really to highlight your New Code and be sure your devs develop well, safe and clean code now. What happened in the past (Overall Code) is less important. and will improve with a better New Code.
To answer your previous question, I’d need a screenshot of your project homepage (both New Code and Overall Code) to see if there is any issue regarding the way your Quality Gate reacts to your analysis.
Carine
I totally agree that checking existing code is less important, but as I’ve mentioned, we only added the overall code filter because the new code filter was not working correctly. Those are there ONLY to catch any new code issues that were not caught by the new code SQ gate.
We always keep the new code tab clean (our CICD actually does not succeed until the SQ gate for new code is passed). However, we still get code smells on new code. For an example, here’s what the code smell filter looks like for the past month on our code:
and what is your setting for the New Code period ?
Thanks,
Carine
We’re using previous version. Does this mean the immediate previous commit? Or the last commit that passed the SQ gate? Because if it’s the previous commit then this might explain our problem (when SQ fails we push in new commits to fix the issues). Would it be advisable to use the ‘number of days’ setting instead?
Hi,
This may be the crux. What value are you passing in for sonar.previousVersion? If it’s something like build_number that changes with each new analysis, then yes. You’re resetting the New Code Period with each commit.
Also, could we back up? This started with your Quality Gate(QG) passing when you think it shouldn’t based on your having QG conditions on Maintainability Rating on New Code, plus Blocker, Critical and Major issues on New Code.
I think it’s worth reviewing what the Maintainability Rating measures. From the docs:
Rating given to your project related to the value of your Technical Debt Ratio. …
- <=5% of the time that has already gone into the application, the rating is A
- between 6 to 10% the rating is a B
- between 11 to 20% the rating is a C
- between 21 to 50% the rating is a D
- anything over 50% is an E
So requiring an A Maintainability Rating on New Code does not mean “no new Code Smells”. Particularly on a large project, maintaining an A rating would still potentially allow you to add a lot of new Code Smells. And as long as those new issues are Info, or Minor severity, they won’t fall afoul of the other QG conditions.
Does this make sense?
Ann
For previous version, yes I think we pass a build number. I’ve changed our new code definition to ‘number of days’ to see if that works the way we expect it to.
So requiring an A Maintainability Rating on New Code does not mean “no new Code Smells”. Particularly on a large project, maintaining an A rating would still potentially allow you to add a lot of new Code Smells. And as long as those new issues are Info, or Minor severity, they won’t fall afoul of the other QG conditions.
Ah, this I did not know. I’ll have a look at the code smells that have been introduced and check if they match these conditions. Though the limitation of them being higher than info or minor might be enough so they don’t show up in our standard filter.
Thanks Ann, your comments have been very helpful.
