New Code Definition with Reference Branch Clarification

Running SonarQube with sonar-scanner, stand-alone installation, with SVN as SCM provider.

I have a long-running branch in which I merge code from the main branch periodically and scan using the -Dsonar.newCode.referenceBranch=master since the default project new code definition is compared against a previous tag version. No merges into the main branch have occurred since the changes are major and potentially breaking.

SonarQube marks code incoming from the trunk branch during the merges (note that in SVN the branch name is trunk, I haven’t made the necessary changes to retag master as trunk since this would break a lot of existing links with branch=master in the name) as “new code” in the feature branch even though it’s already visible in the main branch. I also tried creating a separate branch named trunk under SonarQube which mirrors master and using -Dsonar.newCode.referenceBranch=trunk but this did not help fix the issue - the issues are flagged on the work branch and developers are notified of issues that they have already fixed under the master branch but weren’t merged into the long-term feature branch yet.

Is this the expected behavior of the new code definition when running with a feature branch? I tried looking at [SONAR-14929] - Jira but I don’t fully understand how new code definitions should behave. I would expect the code (and issues) to be identified as existing in the main branch and not be added to the new code definition on the feature branch.


The analysis parameter docs aren’t explicit about it (I’m going to raise that internally), but sonar.newCode.referenceBranch really only works on first analysis of a branch. It sets the new code definition to the specified reference branch when the branch is created. The docs say this about a reference branch (emphasis mine):

Any differences between your branch and the reference branch in the clone the scanner has access to at analysis time are considered new code. To avoid reference errors when cloning a repository, we recommend cloning all its branches.

So this is likely about your checkout and what data SVN can make available about branches other than the one being checked out.


Hello, Ann,
Thank you for the reply. Just clearing some things up:

It sets the new code definition to the specified reference branch when the branch is created

So using sonar.newCode.referenceBranch will mark the branch as being compared to trunk on the first run and will continue using that? Because my new code definition still appears as “project default” even though on the project/branch view it says it’s compared to the reference branch, that’s why I’m feeding it on every runner scan

So this is likely about your checkout and what data SVN can make available about branches other than the one being checked out.

To be clear, you’re saying I should clone the entire repository (trunk and branches) locally? I currently svn switch in order not to have to wrestle with the size of the entire repository, svn diff works correctly but I assume it pulls data from the server - hence the different behavior? I am happy to do that if it fixes things, just want to avoid a misunderstanding because of large repo size.



Where do you see that?

Could you share some screenshots?

It’s been a very, very long time since I SVN-ed. That’s why I was careful not to specifically say what you need to do. :joy: I suspect you need to clone trunk and the branch under analysis. You shouldn’t need any other branch.


Here are two screenshots showing that the reference branch stays as “project setting” - which is previous version for me - even though the project/branch base is compared to a baseline

I’m currently in the process of testing using a local copy of trunk and the work branch to see if that fixes the new code diff.

Just noticed to issues with the screenshots - the warnings reported refer to encoding characters in unrelated files. I also changed the reference branch from master to a Sonarqube-copy named trunk so I don’t crash other peoples’ flows - but the new code definition for trunk stays the same and it’s a 1:1 copy.

@ganncamp I re-executed the necessary scans bringing in all branches which could impact the analysis in any way locally - the issue still remains, the same code is shown as being new although it was brought in from trunk.
Is there anything else I could attempt?


The analysis parameter you’ve been using to try to set the branch’s new code definition reference only works on first analysis. Per your screenshot, I’m going to guess the branch was already in existence in SonarQube before you first tried to use it. So can you update the branch’s new code definition through the UI and try again? Or… what is your project setting? Your screenshot doesn’t show that.


The project settings is previous version, manually tagged on analyses from trunk.
I’ve executed the branch using sonar.newCode.referenceBranch since its creation but, for yesterday’s test, removed both the feature branch and trunk from SonarQube so they are recreated during scans - with default project setting for reference branch and sonar.newCode.referenceBranch for the feature branch scan.