We are evaluating the analysis of our C# code (GitHub repo) with the SonarQube Developer Edition 8.9, sonar-scanner-msbuild-5.2.1.31210-net46, SonarQube Scanner Jenkins plugin v. 2.13, the GitHub Branch Source plugin for Jenkins using Multibranch Pipeline Jenkins job. We use “Previous Version” as the New Code definition.
We are interested in the branch and PR analysis features.
PR and release branch analysis seems working fine at the moment. But we have an issue with the main branch analysis (develop branch).
Most of the time, the result of the analysis on the main branch is 0 New Lines to cover and 0 New Lines to analyze for duplication. What could be a reason for this?
I am not sure how the SonarQube identifies the changed lines in the current version vs the previous one. According to this reply, I understand it is based on a diff with the current state of develop.
So, I wonder if the issue we are facing for the develop branch is because there is a lot of activity in our repository, and many developers are merging almost at the time into the develop branch. So, often, when the SonarQube analysis is running for the next merge, a couple of other merges are done already.
This is based on dates from blame data. You said you’re using previous_version as your New Code Period definition. What are you passing for your sonar.projectVersion value? Hopefully not something that changes with every build?
The value you pass for sonar.projectVersion sets the analysis Version in SonarQube. The idea was that that value would change at each release not at each build. There’s a separate sonar.buildString parameter if you need to record the build number with the analysis.
By passing an updated sonar.projectVersion with each analysis, you’re resetting the New Code Period with each analysis. So you either want to change how your New Code Period is determined, or change what you’re passing for sonar.projectVersion.
Now, that we got the license renewed, I am back to this issue.
I tried your suggestion. Now, each new build analysis reports all the changes since the last version (not the last build) as a new code, which makes sense (because we do not set the version in every build anymore), but it is not what we originally wanted. We wanted to see what new issues are introduced by every new build.
I think resetting the version for each build or not depends on the development/release process. In our case, when we are ready for the release, we create a new (release) branch starting from the latest stable build (i.e. not necessarily the last one).
Could you please give more details on this?
E.g. the latest analyzed version is V1. Then, there were 2 merges done in the development branch: V2 and V3. V2 was merged a couple of minutes earlier than V3. But V3 was analyzed before V2. Will the SonarQube detect the changes in V2 as a new code?
Then there are 2 scenarios: either those 2 new versions were touching the same parts of code or not.
And now, we had a situation of “0 new lines” again, even without resetting the version.
I wonder if it’s explained by the dates from blame data? I traced the changes of the last build (that has 0 new lines according to SonarQube). The date in blame data is August 26 (i.e. when the changes were committed). Those changes were identified just fine by SonarQube in the PR analysis. The PR was merged on August 30 and a new build was triggered at 9am. There were a couple of analysis done on the develop branch between August 26 and August 30.
Does SonarQube compare the date in blame data to the last analysis date to identify the new code? Could that be the reason it did not identify the changes of the last build as a new code? Because the date in blame data (August 26) is less than the date of the previous analysis (August 30, 7am)?
I confirmed this by testing now.
It only works well if we use Squash & Merge. Because then all commits are grouped in one new commit before merging and that commit has the time of the merge in its blame data.
If we use normal Merge PR (Create a merge commit) or Rebase & Merge, they keep all commits history, including the datetime of the commits. So, if the commits were done before the last SonarQube scan, they will not be considered as a new code once merged.
Sorry I couldn’t come back to you sooner on this. I promise I wasn’t leaving you to work it out on your own, but it looks like you did just that! Congrats!
Would it make sense to give more details about this in the SonarQube documentation? I.e. to explain how the new code detection works. It would be then easier to troubleshoot when stumbled on such an issue.
Also, how the SonarQube identifies the new code for the PR analysis. I guess it is not based on dates in blame data?
