Altering the source of Issue Resolutions from MASTER to another branch - Gitflow Support

Currently Issues and Issue Resolutions are copied to new branches from the MASTER branch when the first analysis is created, ant this cannot be altered. This design doesn’t accommodate well teams using some branching strategies other than Trunk Based Development or Simplified Gitflow. Additionally, this is irrespective of whether the New Code REFERENCE branch is different to MASTER.

In pure Gitflow, for example, the DEVELOP branch is the branch where Feature and Release Branches are created from and the MASTER branch is generally only updated with changes after a release is made, remaining only as a copy of what is currently deployed to Live.

By copying only from the MASTER Branch, Issues and Issue Resolutions (Won’t Fix and False Positive) do not all match the code under development. For example: Consider Feature Branch A with new resolutions is merged to the DEVELOP branch and subsequently Feature Branch B is then created from the DEVELOP branch. Issues that were resolved as False Positive or Won’t Fix in Feature Branch A are raised again in Feature Branch B, under the current design. For projects with many active branches this is troublesome and does not align with the new code REFERENCE Branch setting when that is different (eg. DEVELOP branch).

Please consider allowing the source branch for the copy of Issues and Issue Resolutions to be changed. This could either be by always using the Source branch or aligning with the REFERENCE branch or, alternatively, creating a configurable setting that supports different options such as:

a) MASTER (default)
b) DEVELOP
c) New Code REFERENCE Branch
d) Source Branch of the new branch

This will better support branching practises like Gitflow.

Additionally, there does not seem to be documentation that accounts for branching strategies, including Git or other VCS. Can this design be documented with guidance provided for the correct configurations for various branching practises.

1 Like

Hi,

Any thoughts on this? Improved support for Gitflow would be greatly appreciated.

Will

Hi,

Please can we have some feedback on this? Using Sonar with Gitflow is currently quite challenging. Using the Develop branch as the New Code Reference branch rather than Master might be a workaround - keen to hear your thoughts.

Is this feature request achievable or is it too difficult a problem to tackle?

Will

Hi Will,

Thanks for your insight and for the time you took to share it.
As you mentioned in this other post., the 2 suggestions go well together to better support the GitFlow.

From the time being, when a branch is created, issues are synced from the “main” branch of the project.
Using Develop as the reference for your features branches should help you keep the focus on the issues that are new, and thus not yet resolved in this reference branch.

I’d love to understand how the other community members handle this case to better understand how wide is the problem. For example, some users may apply another strategy such as setting Develop as the main branch.

Chris

Hi Christophe,

Many thanks for getting back to me on this. The first reason we discounted changing the Main branch to “Develop” for Gitflow was this statement Alexandre sent me by email, but has not responded when I queried it…

“Issues are copied from the Master for all branches, no matter if a reference branch is set or not. This is why you do not see issue status/resolution copied from your DEVELOP branch to the last created one.”

Can you verify that it is not “Master” but actually “Main”?

The second reason we discounted this was because of this report by Dennis of another Gitflow related synchronisation problem when Develop was used as Main.

Dennis’s issue does not look like it has a resolution and I can’t view the link “fixing it in the near future” which I assume is a backlog item that is still on the backlog.

Ultimately different organisations use variations of these branching methodologies so boiler plate support for each methodology might be too limiting, however Sonar currently seems orientated towards Trunk based development and so this enhancement (and the other one) may reduce problems arising when users are using another branching strategy.

Thanks,

Will

Hi Will,

On the first point, I got confirmation from our team that when a new branch is created, issues are synced from the main branch, not specifically from the one named “master”.

On the second point, SonarQube doesn’t specifically want to promote the trunk-based model. The “master” branch name was used so far for historical reasons (the default for Git), and the branch implementation was trying to fit the needs of most users with a generic approach. We are already working on an adjustment to help you choose the default main branch name for SonarQube 9.8.
The improvements you suggest would help better support the GitFlow model, and I’m eager to get more feedback from our community about it.

Chris

Hi Christophe,

Thanks very much for following up on this. We do appreciate the effort by the team to make a change to help with this problem.

Do you have a ‘Request Community Feedback’ facility, such as a specific section on this site that could link to postings like these, to draw attention to them?

The source branch and the destination branches for any branching and merging often differ and methodologies are rarely followed to the letter, or consistently by all teams and team members. Ideally Issue Resolutions would “follow the code” through all branching and merging and there would also be clear visibility for reviewers to accept or reject False Positive / Won’t Fix resolutions at the PR / Merge Review time.

Finally, the other complication with master / develop / main naming is the change made by many providers (such as Github, Azure DevOps Git Repos etc.) to rename all “master” branches to “main” as part of removing references to slavery terms. Under Gitflow, using Develop as Sonar’s “Main” would differ from Git “Main” and may confuse some folks.

Thanks again,

Will

Thanks again Will.
The “Product Manager for a Day” section is the appropriate section to raise awareness on postings like this one.

Chris

Hi Christophe,

Did this adjustment make it into 9.8 which I see was released a couple of days ago.

Thanks

Will

Hi Will,

With 9.8, the main branch of new projects changes, by default, from “master” to “main”. SonarQube lets you change this default value, and specify the name of the main branch for every new project you onboard in the UI.
It will help better align with the GitFlow model but doesn’t bring any extra flexibility in choosing another branch as a reference for the issues.

Chris

Hi Chris,

Thanks for the reply. We will test 9.8.

Is there a plan to allow selecting another branch as a reference for issues?

Will

Hi Will,

It’s not planned in the short term, but we are tracking the requests on this topic and are actively monitoring this thread.

Chris