We are transitioning our organization to the Enterprise edition of Sonar. We have a Quality Gate in place with conditions only around New Code. We have many feature branches already in progress, prior to the transition, and are looking for a good way to evaluate if these branches are compliant with the gate prior to merge back to master.
We thought it would be straightforward to create a new branch off of master, let that branch build and be analyzed by SonarQube and then merge the old branch into the new one. However, when we do this we are seeing no coverage on “0 New Lines to Cover” on the New Code tab. We have tried a few other merge approaches as well. If we squash the commits on merge, it appears to work (we get coverage and new lines are detected). However, we would prefer it if we could get a standard merge to reliably show our issues and coverage on new code.
I should mention that we are using the “Previous Version” method for setting the new code period.
A “New Code Period” only starts once the branch is created in SonarQube. So that first analysis of the branch effectively creates a baseline, from where New Code is added depending on the setting for the New Code Period.
Another thing to consider is how the git blame dates compare with the analysis date.
This can be a problem when analyzing changes done in the past.
Lines will be considered to be “new” if the git blame date is after the start of the leak period. In this case, the start of the leak period is the date of the first analysis of the branch. So if you are analyzing changes that were committed to git before the branch was created in SonarQube, nothing will be classified “new”.
Could this explain the “0 new lines to cover”?
Interesting. Yes, it seems like we are on the right track at least. We had ruled it out, because when we did our cherry pick it seemed to keep the date intact. It seems the blame in Sonar does not agree with the blame I see from the git CLI. Sonar is showing that the cherry-picked commits occurred on the date of the cherry pick, while git CLI shows the cherry picked commit as occurring on the original date.
I’m not sure why the discrepancy, but it sounds like in order to accomplish what we want, we either need to cherry-pick commits, or squash them in order to get different blame info.