Multiple reference branches regarding one main and multiple release branches

We are currently hosting a SonarQube 8.4.2 server using a developer edition license for branch analysing. Our pipeline consists of Gradle 7.2 using the newest SonarQube plugin for automating our JVM projects.

Our current branching scheme (Git) can be simplified using the following diagram:
Branchschema

We have one main branch called “develop” where our teams are adding features (including bug fixes etc.) using feature branches so nobody works on the main branch directly. It’s our holy grail and every metric there should always be green.
In SonarQube we activated this main branch “develop” as reference for everything else (in every project - currently ~70) and must be changed for every release branch manually - which is fine.
When we are releasing a new version, we create a dedicated release-Branch as seen above. It is used when we have to patch certain bugs but no new features are added ever.

The main branch “develop” and the release branches use the last version as reference for our metrics including quality gate!

This branching scheme worked “okayisch” until now - a new scheme was proposed because of many developers working simultaniously on a release branch when fixing bugs which often led to conflicts when working together on one branch.
The new branching scheme will look like this:
Branchschema-neu

The change is obvious. Normal work on feature branches doesn’t change but when working on a release branch we are going to use specific bugfix / patch branches to circumvent those conflicts happening before.

There is just one problem: When such a patch branch is created our pipeline will run, creating a new SonarQube analysis. But because of the default configuration, that the reference branch of every branch is our main branch “develop”, the analysis is garbage and the reference branch must be changed AFTERWARDS (after the first analysis) to eg. release/1.0 and the analysis must run again.

Thats our problem we’d like to solve. When running an analysis (using Gradle SonarQube plugin and parameters provided) we found no solution to provide the new, alternative reference branch directly in the first analysis without changing everything manually (I call calling the Web API using automation manually as well) and re-running the SonarQube analysis.
The ideal solution would be to provide such a reference branch as parameter (I think that was the now removed “sonar.branch.target”?) or to add an empty branch using the Web API before running the first analysis so there is no need for work AFTERWARDS (changing the reference branch using Web API and re-running the analysis).

I really hope there is one. We are paying good money for this software :wink:
If you have a solution, please provide it or get in direct contact with us (me) as I trimmed my expansive describtion to fit in the post.

Pushed again - it is more than necessary for our companies workflow!

Hi,

Welcome to the community!

Thanks for nudging your existing thread, rather than creating a new one!

Your version is past EOL. You should upgrade to either the latest version or the current LTS at your earliest convenience. Your upgrade path is:

8.4.2 → 8.9.3 → 9.2.1 (last step optional)

You may find the Upgrade Guide helpful.

Once you upgrade, I believe you’ll find new options for setting the New Code Period, both at the branch and project levels. (TBH, I can’t remember when that changed.)

But okay, that part doesn’t get solved. However, rather than being concerned about the analysis of the bug fix branch, why not rely on PR analysis here? In fact, I’d say you should be relying on PR analysis for both your feature branches and your bug fixes. That way, all and only the changed code is under inspection.

If focusing on PR analysis isn’t feasible for you, we’d really appreciate you sharing your use case in detail. You’re not the only one to have raised setting the reference branch from the initial analysis, rather than after the fact for analysis #2 and forward.

 
Ann

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.