currently its seems that sonarqube does only copy issue wont fixes / false positives to a branch on its creation. We would like to have this behavior also, when the master is merged into a branch because otherwise issues occur on branch, that already have been fixed as wont fixes / false positive on master.
We have a policy to not have any issues in a branch before merging. Even since the issues of master only are listed in “all-code” and not in “new-code” it is quite irritating as you always have to filter on “new-code” only.
We use the github flow for development with just a master and feature/fix branches together with sonarqube developer edition.
Ast least it would be helpful to set different quality gates for branches. This way we could set one gate on master to fail on new-code and all-code and the other gate for branches that only fails on new-code.
You would still need to filter issues on new-code for branches as a developer, but at least the gate would not fail.
Is there no one with the similar problem? Are we doing something wrong? Any help appreciated…
Thank you for your feedback.
From what I understand, your need is to avoid getting a failed quality gate on your branches because of some issues already flagged as won’t fix/false positive on your main branch.
Currently, issue status lives independently between branches to support various workflows (ex: maintenance branches…) that don’t want the status to be automatically synchronized.
In your case, is this a need for some feature branches that you plan to merge in your main branch or does it also apply to other types of branches? Are you already using a reference branch as the New Code definition to ensure the synchronization when the branch is merged?
We only have feature/bug branches create from a „master“ branch. When branches are finished they get merged back to „master“, so no branch in between.
We already set the branch „master“ as reference branch, so that „new code“ and „all code“ gets detected correctly by sonarqube.
The problem is the quality gate as we want zero issues in „new code“ and zero issues in „all code“. For master this works great, but since we cannot set a different quality gate for the feature/bug branches we fail there although the issue might already be fixed in master.
Thanks for your reply.
Setting master as a reference branch is a good practice.
I understand that the won’t fix issues created on branch A are not shipped to branch B that made a rebase of the commits made by branch A in Master.
We will investigate this need further.