Dynamically update the Resolution to all branches

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.

1 Like

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.

1 Like

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 @Chris - Any more thoughts on this and the related enhancement request?

Thanks

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

Hi Christophe,

for this resolution sync issue, I just found that this sync may only happens with main branch?
test1 :
1.mark a false positive/won’t fix in branch1.
2. checkout branch 2 from branch1 , so they have same code.
3. do analyze for branch2. FP /won’t fix is not synced to branch2

test2:
1.mark a issue as false positive/won’t fix in branch1.
2. do analyze on main branch which have the same vulnerable code.
3. FP /won’t fix is synced to main branch

So is this by design? it would be greate if you can share more information on this part

Thanks in advance!

Hi @mason,

This thread is a year old. Per the FAQ, please create a new one with all your details.

 
Thx,
Ann