Documentation about "Ignore Issues" seems to be wrong or outdated

SonarQube Cloud
32

Hi,

Thanks for your detailed response.

Most of these seem like pretty pointy corner cases to me.

Do you / your team do this kind of sweeping(?) refactorings often?

And, FYI I’ve pinged the Product Manager to make sure he’s aware of your input.

 
Ann

33

For any given project, this will come up about once every few months. Across 10s of them, all the time. And I want to point out, these aren’t necessarily sweeping changes. And easy example is go:S3776. Perhaps we allow a particular go package to ignore this rule because it makes sense, but not for the project in general. Then, in a branch, we happen to rename that package. That’s pretty run-of-the-mill.

We can quickly get around the problem today three different ways, but all have drawbacks.

  • We can use sonar.issue.ignore.multicriteria... keys in our various in-code configurations. This provides us a traceable history into what we are excluding and allows us to comment each resource-selection as to why it applies. The problem with this approach is that it was described here as an “undocumented hack, not supported in any way”. We’re doing this today, but are worried it will stop working.
  • We can use the sonar.exclusions property, which works the same way but is too broad. Any time you need to exclude a single rule for some resources, you have to actually disable all scanning.
  • We can maintain a single set of resource-based exclusions in the Sonar project, server-side. Here, we lose all visibility into why any exclusion applied to a given selector, all change history, and refactoring changes will break in the conditions listed earlier. In this case, we will probably skip rule exclusion resource selectors entirely. Just too much to hassle.
1 Like
34

Hi,

Thanks for taking the time to detail this out.

In case it helps. the way exclusions are handled hasn’t changed in >10y. You can be confident that it won’t change without a notice/deprecation period.

 
Ann

36

May I suggest a solution that would make me more confident?

Document that it is a feature that will be kept stable, but SonarSource do not offer support for how to use it.

That would give people confidence that it can be depended on for production use but (hopefully) avoid much of the support-issues for a complicated feature.

My current team use it to keep configuration with the source and vissible, most of the team only work in ADOS and thus would never see what exclusions have been made.
Besides, the traceability you get from git is hard to match in a GUI.
Also with peer-review of all PR before merging to main every change gets very vissible when it is introduced.

37

Hi @saas2813,

This feature has indeed been stable for the last ~15 years.

 
HTH,
Ann