Where it is possible to match an issue within other branches of a repository being analyzed in SonarQube, resolve the issue in all branch analyses.
This is most noticeable when there are many feature branches active on the same repository, particularly with legacy code and large teams.
Hi,
To clarify, you’re talking about marking an issue False Positive / Won’t Fix?
Ann
Hi Ann,
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.
Will
Hi Will,
False Positive / Won’t Fix status syncs on first analysis of a branch but not again. For code fixes, that’ll only show up after analysis if the code fix was made in all branches.
HTH,
Ann
Yes. This current design means issues fixed in one Feature branch resurface in the next.
For Branching strategies other than Trunk based Development, such as Gitflow, this can be problematic.
Hi,
Sorry, but as long as the issues aren’t fixed in the code, we’re gonna keep raising them (if they’re not marked FP/WF).
But would it help if you could make your Develop branch the main one in SonarQube?
Ann
Yes.
Perhaps I wasn’t clear.
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.
Hi @Will,
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?
Chris
Hi Christophe,
Thanks for this response.
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.
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
https://blog.knoldus.com/introduction-to-git-flow/#:~:text=Git%20Flow%20is%20an%20abstract,framework%20for%20managing%20larger%20projects
This is the classic diagram that illustrates it.
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).
Will
Thanks for the answer @Will.
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?
Chris
Hi Christophe,
Yes, that is the new feature request described.
Please also review the accompanying (and more important request) here related to Branch Strategy and Issue Resolutions, notably for Gitflow:
There is also an email thread including Test Cases with Patrick Mc and Alexandre from my colleague you should seek out.
Best,
Will
Hi Will,
I’ve just answered your other insight on the related thread.
If we find that the request explained in the present post is a common need, we will consider addressing it in the future.
Chris
