Is it possible to tie the reported issues to the GoLang language? Right now they are not tied to anything and we can’t find a way to run reports on these issues.
Is it possible to change the type of issue from Bug to Code Smell?
Is it possible to change the criticality level, per report type. For example we would want to set the criticality golangci-lint:deadcode to be different to the criticality of golangci-lint:errcheck.
For assigning to the language we suppose that’s something that need to be ‘updated’ in Sonar itself, or at least the GoLang plugin.
For the type and criticality, since the golangci-lint rules are not listed under the rules management interface maybe that is something that can be done by massaging the check style reports?
<error column="3" line="75" message="SA4006: this value of `cerr` is never used" severity="error" source="staticcheck"/>
We could not find any documentation on how Sonar interprets the tags and severity of the checkstyle reports or if everything is always set to Bug/Major.
You can always change the type and severity of existing issues, but I guess you are more interested in the case of new issues.
It is currently not possible to change the type and severity of future external issues (as it is possible with internal ones).
To give you more details, in the case of GolangCILint (and all Checkstyle format), issues with severity=error will have type bug, and code smell otherwise, and issues with severity=info will have severity minor and major otherwise (see the code).
This may seem arbitrary, but keep in mind that we are simply importing these issues, we don’t control or define them, we implement a mapping which make as much sense as possible, but it’s not possible to have a perfect one.
Thanks that source link is informative, so the check style importer is setting the type to ‘Bug’ or ‘Code Smell’ and the severity to ‘Minor’ or ‘Major’ depending on the content of the report. This should allow us to have some flexibility if we want to enable more rule with the GoLang linter but not necessarily make them fail quality gates.
The other part of our concern is that these errors reported are flagged as GoLang, which mean they are more difficult to filter in the reports. This is not something that can be manipulated post import.
See this screenshot were there are 2 ‘bugs’ on GoLang files but they are not assigned to any language:
I have a typo on my previous post, I meant “that these errors reported are not flagged as GoLang”. You got my meaning from the rest of the post anyways.