We have a .NET 6 project which we analyze with SonarCloud. Beside SonarCloud rules we also report issues from external Roslyn analyzers to SonarCloud. Our goal is to ensure 0 issues in the code base through a quality gate.
While we can set that Issues on new code should be 0, it does not seem to be able to enforce that issues on overall code needs to be 0. The approach with only checking new code fails, if for example a new rule is enabled and causes issues in existing code. Or when a change in a class causes an issue in another file.
I guess the context of this is PRs? Or are you talking about overall code? Because for branch analysis, all Quality Gate conditions are taken into account, and you can absolutely create your own Quality Gate that includes conditions on Overall code.
Does that help? Or is the context of this PR analysis?
Context is PR analysis. My goal is to have a quality gate which is checked on pull requests and makes sure that there are no issues in the overall code base.
As I understand it, the problem is this: it’s easy enough to keep the code changed in a PR clean because PR analysis detects issues in new code, and you fix them before merge.
But SonarCloud is constantly updated with new and improved rules, and they can raise new issues in old code. You’re troubled by the fact that these new-old issues show up in a post-merge analysis of the base branch and would like to find and fix them before the PR merge.
Unfortunately, there’s no good way to make these issue show up in your PR analysis, because PR analysis is about what changed and the fact is that these new-old issues are entirely unrelated to what changed; they were always there. The PR had nothing to do with them showing up and it’s basically coincidence that they appear after a merge.
Which is a very long way to say that I don’t have a good suggestion for you except to make sure your Quality Gate
has conditions on Overall code
is green / passing before you deploy to production
Enforcing the Quality Gate on the branch is really the only way to tackle this.
My use case is about changes made in a PR. But changes in a PR can cause issues in files which are not changed in a PR and I would expect them to be considered.
Examples:
A new Roslyn analyzer is added to a project and Roslyn rules are reported to SonarQube
Project settings are changed that new issues are raised in code
ClassA removes usage of a MethodA in ClassB, which results in a new issue in ClassB, that MethodA is no longer used in code
Of those three scenarios, only the last is related to the New Code in your PR (unless you’re adding your Roslyn rules or changing your project settings via the PR).
Unfortunately, the third scenario is a known issue and there’s not much you, as a user, can do about it.
Okay, then they all fall under the known issue. This is something that bubbles up on a semi-regular basis (with a “yeah, we otta do something about that…” kinda response). I’m going to ping internally, but I wouldn’t advise breath holding.
