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

SonarCloud
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