How to set a baseline version for SonarQube

We are running: SonarQube Enterprise Edition Version 8.9.2 (build 46101)

I am working from a codebase that I know already has a number of issues / bugs / smells and I am not looking to fix those (yet).
However what I want to make sure is that any new code that is added doesn’t introduce any more.
The “OverView”, “New Code” tab gives me useful information, but only compared to the previous build, and this is a sliding reference, which means that I could easily miss one. (For instance if A->B introduces new bugs, but B->C doesn’t, and I only see the “New Code” tab for “B->C” I’ll never know that “A->B” introduced issues.

Is there anyway to either:
Set a baseline so that the tab will ALWAYS show me the head of this branch, compared to version xyz of this branch?
Do a comparison between branches? Since the codebase I am working from is the tip of another (stopped) branch know what the SonarQube issue differences are between my current branch and the other one would be a work around.

Any other ideas as to how I can achieve this?



Welcome to the community!


:clap: :clap:

There used to be a New Code Period setting named previous_analysis but that got dropped as being unproductive (as you’ve noted. :slightly_smiling_face: ).

I suspect what’s happening is that you’re using the default New Code Period value of previous_version. (Which is perfectly reasonable. That’s why it’s the default.) And you’re passing your build string as your sonar.projectVersion and so re-setting your version with each analysis, yielding previous_analysis behavior.

As an example, the build string of the latest SonarQube version is That’s version 9.2.4, which was produced from build number 50792. An analysis of that code should pass sonar.projectVersion=9.2.4 and, optionally sonar.buildString= Note that the buildString value isn’t used by SonarQube, it’s mainly there for your record keeping. So you could pass sonar.buildString=Grandma if you wanted to.

Does that help?


1 Like

Hi @PhilV ,

You mention that you’d ideally like to see New Code based on another branch - take a look in your Project Settings under New Code. You can set a reference branch there as the baseline, and all other branches will then calculate what’s new or not based a comparison to this branch.

Btw: You should update your 8.9.2 version to 8.9.6 asap - there’s a major vulnerability in your version (log4j) that’s fixed in the update.


Hi Ann, thanks for your reply, that’s a great insight into the parameters of the scan that I had missed before, you are quite correct that I was passing the full build string as the projectVersion.
So now I have a question about projectVersion :slight_smile:
In order to determine this version Vs previous version, does SonarQube place any rules on how the version should be used, or is a new version simply ‘detected’ by the version string bring different to the last scan? i.e does it have to go “9.2.4” to “9.2.5”, or would a project version of “Foo” changing to “Bar” work just the same?

Thanks for both points Chris! I’ve poked the admin about the update.

I’ve found the setting you mentioned, and also pleasantly surprised that this can be set on a ‘project’ level, or on individual branches, which is perfect for me. For now I’ve set my specific development branch to use another branch as its baseline - nothing has changed in the dashboard as yet, so I’m assuming it will need another scan to come in in order to ‘trigger’ the change.
I’ll look into Ann’s suggestions as well in terms of modifying the parameters, but this will (hopefully!) work great until I can get that sorted.


Yes, exactly. When the string changes, the version changes.