we are on SonarQube Community Edition v9.9.2, which was deployed from zip.
We are facing the situation the we cannot get valid insights to an analysis result before the merge to the destination branch. We are aware that branches are not supported by SonarQube in the Community Edition. Therefore we are running each branch as a new project in SonarQube.
We have merged the latest pull request to develop and SonarQube new code analysis fails because of reported issues
which does not match the results from develop branch’s new code analysis (as you can see in comparison to the second screenshot).
My understanding is that the new code analysis compares the current code base results with the one from the last analysis. How can it be that even though we recreate the picture from the develop branch we get different results here?
I must admit I do not understand why the analysis time should be the root cause. For all analysis, the same basis commits has been used (see marking 1. in below screenshot).
I have tried three time to recreate the result of the develop analysis 2b. I was not able to do that even with recreating the same “history”, here feature/SonarTest2. We also should keep in mind that the checked-out code for 2a, 2b and 2c is the same (all the changes that were merged to develop branch too). Therefore, a comparison against the same baseline should result in the same result, independent from the time the analysis is running. Shouldn’t it, or do I miss a point in my thought process here?
maybe I was not too clear in my explanation of my confusion.
Develop branch (“SonarQube project develop branch”) had an analysis 19 days ago on “commit baseline”, now the developers merged one PR (as you can see in the first repo screenshot in this thread) which creates “commit new code” and SonarQube result was this:
I have tried to recreate the same result in multiple ways, having the same “commit baseline” as baseline and then get the new code “commit new code” analyzed. Each of my attempts was done in an own SonarQube project, but this with the same commit history as for develop, only “commit baseline” and one “commit new code”.
This means all SonarQube projects I have mentioned for develop, feature/SonarTest, feature/SonarTest2 and feature/SonarTest3 have only seen two code states, “commit baseline” and “commit new code”.
The only difference is the time of analysis, “SonarQube project develop branch” had analyzed “commit baseline” 19 days ago where all other “SonarQube project feature/SonarTest branch”, “SonarQube project feature/SonarTest2 branch” and “SonarQube project feature/SonarTest3 branch” analyzed “commit baseline” on the day I have create this support request. The content/code for all of these baseline analysis was the same, and the same goes for the “commit new code” which was the same content/code, just different “git ways” to get to it.
How can it be that I’m not able to reproduce the result when only two points (“commit baseline” and “commit new code”) are taken into consideration? Or is there more from the “SonarQube project develop branch” taken into consideration what I did not recreate in my “SonarQube project feature/SonarTest branch”?
So you’ve analyzed 4 different “projects” (branches) each with analyses of the same 2 commit hashes.
And what shows up as “new” code in each? When you go to the Measures tab and look, for instance at New Lines, do the same files? same lines show up in each project?
2 project (develop and recreation) had the same 2 commit hashes analyzed with different results, and
2 additional projects with the same baseline commit (as above) and different hashes for the second analysis, but I can ensure that the code in these two hashes was the same as for the first point’s second analysis point. The results of both projects matched the “recreation project” I have made on the first point.
I had to recreate the scenario once more because our developers had already made changes to the develop branch. I used the same 2 commit hashes for analysis and there is a slight discrepancy visible.
Yes, you will see the output of the Sonarqube analysis in the Jenkins console log.
For complex builds, i.e. when using the parallel step you can use the Blue Ocean view or its
successor, the pipeline explorer to get the relevant parts of the log.
It seems your using the SonarScanner for .Net and for troubleshooting you should increase the loglevel to get more details, /d:sonar.verbose=true
Thanks for the logs. Having looked at them… I really don’t know what to tell you.
This comes down to the detection of new code. That detection is based on SCM data. I can only guess there’s a difference in the local Git repo, but I can’t give you anything more than that.
thanks for this hint. Weird thing though is, that the same commit IDs are checkout (I verified this once more in the logs) and we always do a workspace wipe + fresh full checkout for each build.
Would it help to get the logs with the verbose output Gilbert mentioned? I could maybe try to tweak something there.
The topic of detection of new code is pretty complex. As I said, I suspect there’s a difference in the local Git repo. But I can only speculate, and I don’t think I’m going to spend much more time trying to help you work around buying a license.
I understand your point and indeed for us it is currently a “license workaround”. This has effect on the support from your side, I see this too.
I would consider to get the paid version of SonarQube but I’m not fully trusting that the problem is solved. I find it concerning that the application seems to be non-deterministic.
Is there a way to mitigate this concern? I would like to understand the current results better from a technical perspective and support you further in getting to the bottom if this non-deterministic behavior.
