Using sonarqube 9.3 developers edition with analysis triggered via jenkins / SonarQube Scanner 4.7.0.2747
I am having some trouble with getting the correct classification of what constitutes new code. My setting for all projects is to be based on the previous version.
The biggest pain point at the moment is that we decided to change our version number from 8.3.0 to 9.0.0. We created 9.0.0 branches in github and once the build was working deleted the 8.3.0 branches. We also deleted the past analyses from sonarqube. However, sq is still reporting 9.0.0 “new code” by comparing to 8.3.0 not to 8.2.0
Related, we recently re-ran all of the analysis for older branches and now the new code analysis for them seems to be way off. For example, 8.2.0 does not report new code since 8.1.0 now it reports it as “Since May 13”. I have noticed in the past that it will say things like “you will see new code metrics after your second analysis of the branch” but this makes no sense if new code is based off the previous version. Why should I need a second analysis in that case? It implies that it is comparing current code of the branch to previous code of the same branch not of a different branch.
“Versions” in SonarQube have a very specific meaning (it’s the value being passed to sonar.projectVersion or set manually for an analysis in the Activity section of a branch). None of this, it should be added, is copied to a new branch when it’s created.
What I think you’re after is the New Code Period known as Reference Branch, which will in fact determine New Code based on another branch.
Colin, I have set the New Code Period to be “Previous Version” and the version number is filled in as part of all of our analysis. The version number (i.e. sonar.projectVersion) matches the branch names shown in the previous screen shot (i.e. branch 8.1.0-branch analysis is done with sonar.projectVersion=8.1.0 and branch 8.2.0-branch analysis is done with sonar.projectVersion=8.2.0 etc)
Are you saying that the new code determination based on “previous version” requires that we are only updating a single main branch? That is not how we do it and in general the new code determination looks correct, it is mainly just this recent version change that introduced a problem from my perspective. (As well as limited ability to re-run past analyses.)
A New Code Period based on the previous version is entirely isolated to what is happening in that branch, and the analysis related to the last version entry (that you see in the Activity tab of the branch) It doesn’t take into account what is going on in any other branches.
Only when you are using the Reference Branch new code period, is it actually considering that which is new as compared to the reference branch.
No. It just implies that the branch will have regular version markers (new versions passed as sonar.projectVersion, or versions added on the Activity tab)
This sounds like the response to my question is yes. If each branch is only analyzed with a specific version marker, then it won’t properly determine the new code. This design seems to include one long-lived branch that is periodically updated with new version numbers. i don’t understand why other analysis for the same project aren’t used to determine new code, whether they are from the same branch or not.
Using a reference branch is very difficult to manage as far as I can tell.
When I analyze 8.1.0-branch, want the reference branch to be 8.0.0-branch
When I analyze 8.2.0-branch, I want the reference branch to be 8.1.0-branch
When I analyze 9.0.0-branch, I want the reference branch to be 8.2.0-branch
etc.
And our sonarqube is doing this process for a number of projects, not just the one I posted about, so if there is manual maintenance involved (e.g. change the reference branch manually from time to time), it is not practical for us.
@Colin Based on your pointer about the activity page, I was able to fix my short-term problem by deleting the past analysis for 8.3.0. Now, I see the correct “new code” period for 9.0.0. Thanks!
As to my other, more academic question about recomputing analysis for previous versions/branches, it seems that the “MAIN” branch is treated specially. For my branches named X.Y.Z-branch that are not the main branch, even though I have marked them to not be deleted, they are treated the same as other branches and new code is just any code introduced for that particular branch since the previous analysis of that same branch.
However, the main branch keeps a history of version markers not tied to the branch name that is considered the main branch. So, in my case, I had kind of lucked into a good design which keeps the new code determination correct for “main”.
While we are working towards releasing version 1.2.3, branch 1.2.3-branch is the main branch and the analysis is tagged with projectVersion 1.2.3
Before 1.2.3 is completed, we start working on 2.0.0-branch and it will start collecting analysis with projectVersion 2.0.0 but it will not yet be the main branch so it does not impact the “new code” period yet
Once 1.2.3 is GA, we delete the 2.0.0-branch branch from SQ. We then rename the “main” branch to be 2.0.0-branch. So, the next analysis of the 2.0.0-branch shows proper new code determination since it is now the main branch and treated differently.
The downside of this previous approach, which I had noted previously but not really focused on is that we need to do a subsequent analysis of 1.2.3-branch in order for it to be preserved in sonarqube. And that final analysis is treated like a brand new branch so the New code period is off. It still is useful for tracking the overall quality metrics over time, but not accurate in the determination of new code.
It seems that I can modify this process slightly to take advantage of your other suggestion. I did not realize that I can specify the reference branch for New code on a branch-by-branch basis. So, on the final analysis of 1.2.3-branch (after 2.0.0-branch is now the main branch), I can make sure to specify the correct previous version reference branch.
I will give this a go and let you know the outcome
