This would be for all issues resolved in other branches on the same file/line, either through code fixes or resolutions of False Positive or Won’t Fix. These should propagate to other branches automatically, where they can be matched.
This PM4AD request is for Sonar to update statuses of the same issue in all branch analyses as Fixed/FP/WF when they are resolved in a branch, where they can be matched.
Re: Changing the Main Branch.
Unfortunately Alexandre tells us that all issues are copied only from Master on branch create. Until that is changed we can’t set Develop as the Main branch. There is a separate request here to look at that.
Currently, the issue status propagates from a branch to its target only in case you use a PR or the concept of reference branch. Otherwise, issues live independently into the branches. It works this way because, if you consider for example the case of maintenance branches, you may want to flag an issue as Won’t fix in a maintenance branch but not in the development branch.
In your case, do you make any distinction in the workflow between different types of branch?
Like many (large) organisations we use Gitflow as the branching strategy. This is a lot more involved that the simple model of trunk and maintenance branches you mention. Under Gitflow it does mean that there can be many feature branches under development for a release.
Please see these references to understand Gitflow.
As you can see feature branches cloned from the Develop branch are the primary (and most important) focus of this strategy. As you will appreciate if the issue resolutions were synchronised between branches when they were resolved this would greatly reduce repetition and frustration. Note that under Gitflow, the Master branch is only used to reflect the current release, and for creating small hotfixes so is used quite differently from other branching strategies such as Trunk Based Development.
The wider problem here is that Sonar currently does not handle this branching strategy well, particularly if it is true that Issue Resolutions are copied from Master on branch create (not Develop) and only once (not updated dynamically).
Maintenance branches from the trunk-based model were just an example. GitFlow is for sure very popular, and I think that there’s indeed room for improvement in the way SonarQube handles this branching strategy.
My understanding is that you would expect issues resolutions to be automatically updated from master to the develop and all features branches, isn’t it?
Would you see another major problem in the way SonarQube handles GitFlow?