Hi Ann,
@swetan27 raises a very important point.
As Sonarqube Enterprise admin for several years now, i’ve learned:
you must activate the Track uses of “NOSONAR” comments rule
you must also activate the Track uses of “@SuppressWarnings” annotations rule with an appropriate
whitelist that only contains code smells but no rules with severity CRITICAL.
Our developers are mostly eager to keep their code clean, but there are also external developers involved with their own opinions. Some don’t give a shit on our styleguide and claim they know better.
From the rule description of the Track uses of “NOSONAR” comments rule =
Any issue to quality rule can be deactivated with the
NOSONARmarker. This marker is pretty useful to exclude false-positive results but it can also be used abusively to hide real quality flaws.
This “but it can also be used abusively to hide …” is also relevant to the sonar.exclusion property,
which may be used i.e. in pom.xml for maven builds.
To be sure it’s not used abusively i need to check whether:
sonar.exclusions is used
and
sonar.exclusions has more than the global exclusions or the project exclusions.
If this is the case i would need to break the pipeline.
This should be more convinient for Sonarqube admins, means i’m pushing for centralizing this on the server, otherwise it opens the gates for abuse.
Gilbert