Im using SonarQube Developer Edition Version 9.5 (build 56709)
I’m building C++ code with the linux x86 BiildWrapper. I don’t have any special plugins.
I’m integrating SonarQube with Jenkins and Bitbucket.
I’m fairly new to SonarQube, and I quite like that its easy to setup. However, there are a few things that I wonder if its possible to do. I can’t seem to find my question after some limited research.
So here’s my problem.
When I push a branch that originates from master I do not get the difference from master. It seems that I need at least two commits on my branch to get any “new code analysis”. This breaks as we continously squash our history. Thus, I only get the “new code” analysis once I merged a branch to master. I tried changing the Project setting for “New code” to reference branch master, but this did not change in subsequent analyses as far as I could tell.
The new code analysis also only shows that I may have introduced some issues, not all the issues that I removed. Thus, the analysis often become “failed” even though I may have resolved many issues. Alas, If i removed several critical, and introduced one minor issue the analysis will still “fail”.
What I would like is to always compare a branch to master, and I would also like to see the improvements. Are there any settings to achieve this, or any plugins?
Yes, this has been on the list for a long time, but just hasn’t bubbled to the top yet.
This is and is not on purpose.
The “is” part: If you’re just looking at raw issue counts, then as you alluded, you could fix 3 minor issues and introduce 2 blockers, and still look good with a reduced issue count. That’s why we focus the default Quality Gate on New Code so that newly introduced issues don’t get lost in the shuffle.
The “is not” part: Not only do we focus the default Quality Gate on New Code, but we focus it on Ratings on New Code, specifically the Security, Reliability and Maintainability Ratings on New Code. For Security and Reliability, that boils down to looking at the severity of the worst issue - so your one minor issue would be overlooked. For Maintainability, the rating is essentially about the effort to fix newly introduced Code Smells versus the number of new lines of code. Again, your one minor issue would still be intentionally overlooked (unless it was a real hum-dinger!).
What is your project’s (your branch’s) New Code Period set to? What does your checkout look like?
Thank you for the answers. I understand that there may be issues with just looking at the number of issues. I will play a bit with the quality gate for new code and find a good compromise. E.g., perhaps allow minor issues, but no major or above, or similar. I can likely find a setting I’m happy with.
I haven’t used the new code period (if you refer to the new code setting for floating number of days). I have tried the “previous version” and “reference branch” settings.
I played around a bit more with the new code settings but I’m still not sure if I manager figure out how I get what I want. I find it a bit confusing with the difference between “previous version” and reference branch. What does “version” mean. I initially though it was the previous commit, but that does not seem to be it.
When I choose a branch or a pull request and look at the new code tab in the overview section I would like the new code to be the difference from between the last analysis and the previous analysis on that branch, while the “overall code” should be the analysis of all the code.
The “version” in SonarQube changes when you change the value you pass in to sonar.projectVersion during analysis. The (somewhat Maven-centric) assumption is that you’ll only change that value after you release to production.
You can get this behavior by changing the sonar.projectVersion value with each analysis, e.g. by passing in your build number. And we don’t recommend doing that. Doing that wipes the New Code slate clean with each analysis. And then: Quality Gate failing because you just introduced some new Blockers? No biggie; just analyze again to reset the New Code Period and move those issues into old/overall code.
Ok. Thanx. It seems like a bad Idea to change versions all the time
I’m still confused thoug considering the analysis and the overview of “New Code” and “Overall Code” on a branch. When I’m comparing with the master branch I don’t really understand how to interpret the results.
I’ll give an example. Om master I have, lets say, 10 code smells.
Let say I then create a branch and I fix 5 of them, and I introduce 1 new. Here is what I see on our sonarqube web.
On the branch “Overall code” I see 11 code smells (all that were on master plus the one I introduced)
On the branch “New Code” I see 0 new code smells.
What I would expect:
On the branch overall code I would like to see how it would look after a merge (the status of the branch). Thus I would like to see 6 code smells.
On the New Code I I would expect to see at least 1 code smell, as I introduced one.
Am I getting things wrong? Perhaps you answered just this before - but I didn’t realize at the time?
