Clarification on Reference Branch Analysis

Sonarqube Version: 9.1

Hi,

I am trying to set up my SonarQube with branch analysis such that it calculates New Code as code that is not on our main (reference) branch. From my understanding, this should be achieved by setting New Code period to Reference Branch, however, I am seeing a strange issue: it appears that when a different branch merges into our main branch, the new code period seems to be calculated as every commit after the merge into main, rather than all code that is different from main.
This leads to a situation where our quality gates miss that a feature branch might have issues until it is merged into the main branch, at which point, it is scanned with new code being defined via “Previous Version”.

An example:

  • Two developers working on a repository in branch feature/task-one and branch feature/task-two
  • Developer 1 creates a commit 1 on Oct 1 to feature/task-one, our CI pipeline picks this up and runs a build and scans via sonarqube, potentially finding issues
  • Developer 2 finishes feature/task-two on Oct 2 and merges it into main as commit 2, our CI pipeline picks this up and runs a build as usual
  • Developer 1 creates commit 3 on feature/task-one on Oct 3. Our CI pipeline picks it up and runs a build and scans via sonarqube, however, it only calculates “new code” as code submitted since Oct 2, missing commit 1 from analysis and any issues from commit 1
  • Developer 1 finishes feature/task-one and merges into main. Our CI pipeline picks up this commit and runs a build, scanning all new code since previous version. Commit 1 is calculated as new code, Sonarqube quality gates fails the build due to unresolved issues from commit 1.

Is this intended behavior of the reference branch setting, or am I missing something in my configuration?

Additional details that might help:
This specifically occurs in a monorepository that has multiple npm components, each with their own sonarqube project. When a build is triggered on our pipeline, our pipeline determines which projects need to be built based on what has changed since the last successful build.
I have not checked to see if feature/task-one and feature/task-two needs to be tasks on different npm components for this to occur

Hi,
Do you do merge commits or use the rebase workflow in git?
Unfortunately there’s a bug when using the merge workflow. Here are the details: [SONAR-14929] New Code using a 'reference branch' doesn't detect changed code with git merge workflow - SonarSource

We use merge workflow. Does this work better with a rebase workflow?