Developer Edition Handling of branches in Git

SonarQube
1

We are using the Developer Edition of SonarQube version 8.4.2 (locally installed on our own server), Git as version control and we are observing a behaviour on branches which confuses our team a little bit.

Description:
We can observe in Sonarqube’s code analysis for a developer branch it will show code parts from the master branch as analysed which are not part of the given branch.

It looks like the separation of the new code on the branch and the existing code state on the master (from wich the dev branch has been created) seemed to be not correct.

Details:
We are using simple feature branches which means we create a branch from master via:

git checkout -b FEATURE-1

Afterwards we work on that branch for a time period and from time to time we rebase that feature branch (FEATURE-1) with the new code from master via:

git checkout FEATURE-1
git rebase master
git push origin --force-with-lease FEATURE-1

Before we merge into master we squash into a single commit and finally we merge the feature branch into our master via fast-forward only. This results in a single commit on master only.

Assumption:
My assumption is that this model of branching could cause this problems of analysation.
Can someone acknowledge that ? Or does exist another solution for this problem?

2

Hi,

Welcome to the community!

Could you expand on what you mean here? When you’re analyzing a branch, it’s always going to analyze all the code, even the stuff that’s straight from master…

 
Ann

3

Hi,

first thanks for your answer…

the problem is that code parts will be shown as new on the branch (shown in “New Code” area" ) which are part of the master branch and not being part of the branch which is analysed.

In Git I can identify only the commits on a particular branch even after git rebase master etc. or after a squash. Currently it looks like SonarQube is not able to correctly identify the things on the branch in comparison to the master branch. During the analysing process for each branch we always give the branch which is analysed to SonarQube via the following command:

mvn clean verify -Dsonar.host.url=$SONAR_HOST_URL 
   -Dsonar.login=$SONAR_AUTH_TOKEN
   -Dsonar.branch.name=${BRANCH_NAME} sonar:sonar

If I correctly drill it down it looks like SonarQube does not correctly handle the cases where we rebased against our master branch … interestingly the code which is shown is already analysed on the master build before the branch so from my point of view SonarQube could know that those parts are already being analysed…

5

Hi @ganncamp, can someone take a deeper look into that? Or is this already fixed more recent versions of SonarQube developer edition?

6

Hi,

The classification of code as “new” in branches depends on the setting of the “New Code Period”. Check the menu “Project Settings -> New Code”.

For most settings of New Code, lines are classified as new depending whether they were modified before or after a threshold date.
The threshold date is initially set to the date when the branch was created in SonarQube and it can later change, for example when a different version is set.
SonarQube collects blame information from git with the last modification dates for all lines and compares those dates with the threshold to classify the lines as new.

So what’s probably happening in your case is that when you rebase with master, changes that were done in master after the branch was created in SonarQube are being classified as new.

Note that the detection of New Code in pull requests works in a very different way. In PRs, we get use git to check what actually was modified in the PR compared to its target branch, so what you see in SonarQube as “new code” should match what you see in git.

In v8.4 we introduced a new setting for the New Code to cover your use case, named “Reference Branch”. With this setting, the detection of “new code” works in a similar way to PRs.

2 Likes