SonarQube Community Edition, Version 9.9 (build 65466)
We’re running the scan via the dotnet command line tool, dotnet-sonarscanner, version 5.13.0.
We have a stage setup in Jenkins to fail when any of our sonarqube quality gates fail.
This stage fails when running against master because it thinks that all of our code since the inception of the project is new code when running against master.
We could try to change the comparison point when running against master, but frankly I don’t think new code makes sense when running against master. It is most useful on PR builds.
How can we disable the new code analysis for master builds?
We tried passing “/d:sonar.newCode.enabled=false” as a parameter to the dotnet tool, but this did not seem to make any difference. Are we doing something wrong? What else do we need to do to turn off new code analysis for the master branch?
You can’t. What you can do is improve the understanding of what’s “new” in your main branch.
New code detection is crucial on PRs. But it’s also important on branches.
How often do you deploy? Have you deployed since initiation of the project? Because the idea here is that making sure each new deployment is at least as good as the last one. SonarQube releases every ~2m. So the New Code definition on the project is since the previous release. And we check both that AND PR analysis. Because even if your PR Quality Gates are pristine when you merge, it’s still possible for problems to creep into the main branch. (I skip ‘how’ for now, but we can dig into this if you like.)
So monitoring the quality of new code in both PRs and main isn’t even a belt-and-suspenders approach. It’s more like fastening all the buttons on your suspenders.
Yeah, that makes sense. Didn’t think about measuring code since last deploy as new code, but that makes a lot of sense.
Two follow up questions.
First, how do you mark a specific commit as “deployed” so that the new code analysis is not comparing the latest commit against the first commit?
Second question is related. The current repository I’m working on is a collection of internal libraries. Does this same concept of “changes since deploy” work in this case? I’m assuming it would be changes since publish instead. Which given that publishes are automated should really be practically the same as the PR analysis.
You used to be able to do that via the UI. That was removed in recent versions for… reasons.
And the underlying web service was left in place. The thinking is that the main use case is automation: that the same job that deploys would also mark the deployment in SonarQube. I believe you’ll use the api/project_analyses/search to get the analysis ID.
