[SonarQube CSS] Suppress sonar rule in code?

Using latest SonarQube 7.9 LTS:

How is it possible to suppress single Sonar CSS rules in css files?
The //NOSONAR comment seems not to work.

This would be important for rule css:S4649 and icon fonts.

Kind regards,

1 Like

Don’t you want to use won't fix resolution in SonarQube UI?

We develop medical software and the results of the static code analysis needs to be reported. If we can not suppress it by code, we would have to export the resolutions of SonarQube.
Also with resolutions managed in SonarQube we would need a backup strategy for the Sonar DB.

I don’t know your context exactly but it seems a long shot to ask for the support of // NOSONAR (which we don’t really recommend) in order to share sonarqube results.
Some simpler way to do so could be to share some SonarQube instance and why not via SonarCloud :sonarcloud: ?

Why we don’t recommend usage of // NOSONAR :

  • This is specific static analysis tool invading the source code, and we are not fan of this.
  • It is not specific to one rule : you will shutdown all the issues on that line
  • Once the issue on that line is fixed, it is very hard to know when and how to remove this comment
  • It is hard to track those comment over time.

Sorry thats not what we need.
Here would be my suggestion how to solve this best:

Provide a way to export all won’t fix/false positive issues to a file like sonar.properties which can be checked in with the code.
An analysis read this sonar.properties file and import the suppressed issues to SonarQube UI.

With this way I can still manage and control in the UI what issues are suppressed, but have a configuration as code approach where everything is stored together with the source code in SCM.

Additionally I would love if Sonar would also show java issues that have @SuppressWarning annotation with the Issue status like ‘false positive’ and using blame information to relate them to a user.

I believe this conversation is getting a bit out of topic.
So let’s be clear : we don’t plan to support NOSONAR comment in CSS plugin. We support it on other languages mainly because of legacy support of this feature.

Then, sorry, my mistake, I suggested a solution because I infered your problem but I actually have no idea what your problem is exactly. Could you try to clarify exactly what is the problem you have ? is it to share marked issues with a customer after delivering your code ? is it something else ?

OK I try to explain:

For medical software regulations require to execute a static code analysis and to document the analysis setup and the analysis results in a signed document that is stored in a validated quality management system.

As we have chosen to use SonarQube for static code analysis this means for us:

  • We need to validate the SonarQube version we are using that it meets our expectations and create a signed report document about this
  • We need to define the rules that shall be checked during static code analysis and document the activated rules in a signed document
  • We need to create a report about the results with all open issues found in the code in a signed document. Any found issue needs a rationale why it does not affect the safety of the software. This rationale is part of the report. All false positives would be closed in the SonarQube UI so we don’t have to include them in the report with a rationale.

Now after some years there is a problem with the software and some auditor requires to proof the results of the static code analysis. To do so we would spin up the docker image with the sonar version we were using at that point in time, import the quality profile and run an analysis on the git tag. The results would show up much more issues, because the false positives are not closed anymore (without restoring the old sonar db). So the auditor would find a deviation to our signed report document.
Best solution for us would be to checkin all false positive suppressions independent of a programming language to the git repository, so that they are preserved for later analysis.

For java this works great with @SuppressWarning, but for CSS issues we did not find a solution yet

Hi Michael,

Thank you for taking the time to explain your use case.

It seems to me that for this use case to work you would need to export all project issues. SonarQube does not currently support this feature. A ticket exists for it SONAR-10534 but no deadline is planned at the moment.

The only solution right now is to create a backup of the database.

what is the recommended approach instead of using a NOSONAR comment for CSS? We find it invaluable in persistently documenting why something is an exception to the rule, for example

return Math.random(); // NOSONAR javascript:S2245 demo can use non-secure randomness

Our experience is that when we resolve issues in the sonar UI and put effort in explaining it in the comment and review it there, whenever code gets refactored, all is forgotten and issue has to be re-evaluated from the scratch without any prior context. This gets tiring very quickly. In contrast, as long as the line with NOSONAR comment stays intact, the existing comment can be easily reasoned about in the context of the code review, and we don’t have to actively do anything if no change is required.

1 Like

I fully agree with @vojtech.bisek here. A NOSONAR comment can document why some code was written in a specific way. Such documentation should always be CODE FIRST. As a developer, when I want to know why something was not implemented beautifully or would trigger some static code analysis, I would expect to find some explaination directly there in the code where the problem is and not having to open some additional tool. Also with NOSONAR I can kill two birds with one stone by disabling a rule AND documenting the issue with a single user interaction, instead of having to document it in code and then copy-past a second time in SonarQube UI.

Also when I look for example at Node, where there exist tools like ESLint, TSLint, StyleLint and others, the ecosystem best practices is definitely to disable linting rules in the source code. A developer should not disregard ecosystem best practices or company policies to comply to some additional tooling. Even if it is not the recommendated approach, it should still be possible to use the alternative.

1 Like