How does SonarQube determine "Previous Version"?

  • which versions are you using: SonarQube Developer Edition Version 8.5.1 (build 38104)
  • what are you trying to achieve: Previous version for New Code should start at git tag 2.20.0, not 2.21.0-RC11
  • what have you tried so far to achieve this: manually set New Code Period to a Specific Analysis

When we create a release in our project, the git commit is tagged with a tag like 2.20.0. We also create release candidates twice a week, which are tagged with a tag like 2.21.0-RC11.

When we used SonarQube Community Edition (version 6.something I believe), the New Code always started from the latest release (e.g. git tag 2.20.0). We have now upgraded to SonarQube Developer Edition 8.5.1 and now the New Code is starting at the latest release candidate (e.g. git tag 2.21.0-RC11).

How can I tell SonarQube Developer Edition to start the New Code at my release tags and not at my release candidate tags? (Apparently this was possible with the Community Edition.)

Currently I have configured the New Code to start from the Specific Analysis for the last release. But I will have to change this manually every time I create a release.

Hi Cdlans,

Welcome to the community and thanks for this detailed explanation!

My understanding is that both “Releases” and “Release Candidates” live in the same git branch, the main tool you use for distinguishing them being git tags that you assign to the specific commits. Is this correct?

Let’s summarise the ways you can set your New Code Period in SonarQube v8.5:

  • Previous version
  • Number of days
  • Reference branch

The Previous version setting is based on the sonar.version parameter value passed to the scanner OR if your project is a maven project, to the version attribute of your POM.xml file. This means that, regardless of the tag of your commit, you can control what value you pass to this parameter and thus, control the New Code Period automatically.

Another option is to create a git branch per release and release candidate. This would allow you to use the “Reference branch” setting (with your latest release branch as your reference). However this would require changing your git habits.

Does the above help?

Best regards,
Daniel

Hi Daniel,

Thanks for your quick response and detailed explanation. Maybe you want to consider adding the info that the New Code / Previous Version is based on sonar.version or the pom.xml version to the documentation, because I was looking for this bit of information for a long time.

Now that I know this, I realised that the change in behaviour is not due to the upgrade from Community to Developer, but due to the transition to Jenkins multibranch pipelines, which happened at the same time. Previously our RC builds were done in a separate job which didn’t run the Sonar scan, but now RC builds are done by the one job that builds every commit, including RCs and real releases.

I will probably just configure the job to not scan RC builds, because the RC build itself doesn’t change any code, so does not change the code quality.

Thanks for your help!
Cdlans