We recently started using SonarQube against some legacy code, and SonarQube found a bunch of issues which we won’t fix immediately. We’re using SonarQube to fail builds with NEW issues but not to worry about the existing issues. The definition of New Code for this project is set to “The New Code will be based on the analysis following the previous version”. None of the existing issues have been reviewed.
That was fine until we upgraded to a new version of SonarQube which detected some additional issues; also, at about the same time we spotted that some files were not being analyzed, so we added them in, and they contribute yet more issues. These recently-uncovered issues are no more important than the issues SonarQube had already found, but because they were not detected in the previous version they are reported as “new” and are thus causing builds to fail.
What I tried was to create a new branch off master, and then change the definition of New Code to use this as a Reference branch. I expected master builds to not report any new issues at that point, but all the recently-uncovered issues are still being reported as ‘new’.
When updating SonarQube, we indeed provide new rules, which can find previously undetected issues. However, even if we detect a previously undetected issue, the New Code VS Old Code is respected. I.e., if we detect a “new” issue, but it’s in “old” code (which isn’t part of your New Code), then it will not be treated as a new issue. The same is true for “old” files that were previously unknown to SonarQube. If you add them, they should still be detected as old code. So, your Quality Gate should be fine.
Unless you disabled SCM data. If SonarQube has no SCM data, it cannot know what are new or old files. In that case, these old files that were previously unanalysed could start raising issues as “new”. Did you disable SCM data (sonar.scm.disabled=true)? If not, what SCM are you using (Git, SVN, Mercurial)?
This should work. Did you re-analyze your master branch? For the change of New Code to take effect, you need to re-analyze.
Thanks very much for the response. We’re using git, I haven’t yet been able to work out whether we’re setting sonar.scm.disabled.
When I tried the Reference branch solution I didn’t re-analyze - thanks for pointing that out.
As it happens we found a different solution to our problem, we needed to raise the product version number anyway, and at that point all the newly-reported issues stopped being reported as new.