Ann,
Off the top of my head, I can point out three scenarios where this will be a problem. For each, assume we’re following the SonarQube recommended path of having scans be a part of our CI build pipelines. For each build on each branch, we get SonarQube feedback. Failures cause the pipeline to fail, making sure we deal with problems early while it’s still inexpensive to do so.
Scenario 1: A developer renames some code on a branch where an exclusion applied.
If we have a master list of exclusions for the SonarQube project, not changing at the same rate as the code, then we have a problem. The exclusions will no longer apply and cause our SonarQube scan to fail. Now the developer has two options:
- Add a new, temporary rule to the project for the rename. And then try to remember to remove the rule after all branches with the previous code are retired. Of course, this won’t happen.
- Ignore the sonarqube failure. At which point, why have the scan?
Scenario 2: Code is refactored on a branch. New exclusions apply, previous ones no longer apply
Again, we have the same problem, except now you can’t just add a rule. The most likely scenario is that the developer will remove the old exclusion and add their new one (directly or through an admin). This will break all other in-flight branches or force the developer to change their design to avoid a SonarQube limitation.
Scenario 3: A developer removes an exclusion after a change on a branch.
A developer is upgrading some code. With the new code, an exclusion is no longer needed and they want to see if they can remove the exclusion with their changes. They must delete their exclusion to test this.
Now, all other in-flight branches are broken until the exclusion is put back or the change is pushed through all branches.
Also, in each of these scenarios, the SonarQube exclusion changes are invisible to the dev team. It’s not in the code, so it’s not in the PR/MR changes. There are no comments as to why a given rule is excluded in the UI, no change history that can be used by the developers.
This is pretty surprising. Rule exclusions using path selectors are based on the configuration of the code being scanned, and branches are different. Both where the code is located may change and what exclusions make sense may change. It would be more surprising if all your path patterns and exclusion needs stayed the same across all your branches all the time.
Keeping these exclusions in code makes sense and seems like a pretty common theme. Not just on this thread, but this other thread, this SO post, in an actual project, etc. Basically, there is a lot of examples of people needing this use case if you do a quick google search.