Base branch for new code

  • which versions are you using (SonarQube 7.9.5)

  • what are you trying to achieve (Upgrade to latest SQ release with minimal impact on project)

  • what have you tried so far to achieve this


There is an issue that prevents us from migrating to the SQ version 8.5 and above.

As the concept of “long-lived” vs. “short-lived” branches has been dropped, the reference for “New Code” needs to be configured explicitly in the UI per project or per branch. The options are

  • A previous version (release, …)

  • Number of days

  • Specific Analysis (only available as branch-specific setting)

  • Reference branch: This option has been added again with 8.4 similar to the target branch set with the “” property in <= 7.9 but it can only be configured in the SonarQube UI (per project and per branch). Usually this would be set to “develop” so all changes made in the branch are considered “New Code”.


Here is the problem:

We are using multiple “develop-like” branches in the same repo for different variants of the product which are developed in parallel, so feature branches are created from and merged back into these branches. With SonarQube 7.9 we just set the target branch name in the Jenkinsfile of the “develop/RAM_A” branch to “develop/RAM_A” so whenever a new feature branch was made from it, the correct “develop” branch was used as reference.

With the new SonarQube versions this (setting the “Reference branch” for new branches) can only be done with the UI and admin privileges (for the project) so this is not feasible and does not work for us.

Explored Workaround and issues with them:

  1. Use Rest APIs to set the “reference branch for new code” in each “develop like” branch. For each feature/shortLived branch that is created, they will inherit this property and set the reference accordingly

    • Setting the reference branch via the REST API for a branch would require that the analysis of the branch was already done, and since the analysis needs to be repeated after changing the reference branch, this means: run analysis, change reference branch via REST API, run analysis again
  2. Create separate SonarQube project for each “develop like” branch with desired configuration “once” (from GUI or Rest API) and use them to perform analysis for related short lived branches.

    • This means a lot of maintenance overhead and for the same reason we do not use a separate Git repo for each of the variants, we do not want to use separate SonarQube projects for each variant.

The response of the sonarsource in this thread (Why cant Code Period start from my main branch when scanning a feature branch?) was negative (they have no plans for changes in this area)

Please suggest any ideas or alternative solutions are of course welcome.



I don’t have any answers you’re going to like. I’m moving this to the Suggest New Features category.