I found this thread in which there is a discussion about how issues flagged as false positives would reappear after the changes had been merged. And it appears that the intended behavior is for issues to stay resolved after having been marked as “false positive” or “won’t fix”.
I’m just wondering if there are some cases where it would be better to not have that behavior, and instead have the issues reappear (or continue to appear) in the default branch analysis results.
Considering that I work with code bases that existed long before we adopted SonarQube, there are a lot of existing code smells in the code. And it seems like every time you make a pull request that touches any line that has a code smell on it, that is reported as part of the pull request analysis. I will admit that this is valuable, because it allows us to slowly resolve code smells while we work with the code. However, that is usually only viable for small local changes that have a low effort requirement.
I think it would be useful to have a resolution type that tells SonarQube that the developer acknowledges that the issue is relevant, but is beyond the scope of the pull request. This way one can leave issues as unresolved in the main branch, while still allowing a workflow where the issue report on pull requests should be worked down to being completely clean.