we are using SonarQube Server / Community Build (9.9.3 LTS) to scan our Go and JavaScript/Typescript projects. Now we have issues to reasonable meet the code coverage goals in the default quality gate and don’t want to define an own quality gate.
We also build C# application with SonarQube scans included and there is the option of tagging files with “ExcludeFromCodeCoverage” and then they are ignored in the coverage results.
I was wondering is there a similar way for Go and JavaScript/Typescript?
The only option documented I could found so far was Suppressing the issues on a given line, but first I’m not sure if this will also exclude the lines from code coverage calculations (because of the wording “suppress all issues on the line”- are coverage misses ‘issues’?) and second we would have to do this tagging per line which could hamper readability of the code a lot.
In addition, going with sonar.coverage.exclusions in the project settings would be also not the best way because there are no common pattern and the exclusion would be more on a file per file basis.
I hope you can give me some further insights on how to solve this topic.
By “default quality gate”, I assume you mean the Sonar way Quality Gate? If so, it’s only requirement for coverage is that 80% of new code be covered by tests. It doesn’t require you to do archaeology in your code base to dig up old, uncovered files and write tests for them. Just make sure that the code you’re working on today has tests. That’s it.
By “default quality gate”, I assume you mean the Sonar way Quality Gate?
Yes, this is correct and we are aware of the details with the “new code”. Unfortunately, now our developers say that some lines are in the code base for future cases but they actually cannot be hit today, e.g. check if an error is returned but for now an error cannot be returned.
They’re ignored in the coverage results, but not by SonarQube.
This is weird because with C# the exclusion is working, or could it be because we use DotCover and Xunit to generate the report and feed this one into SonarQube?
If so, are you aware of a tool we could use to feed in the filtered Go coverage results into SonarQube?
Is this line-level or file-level? I’ve been reminded that for files that do show up in the coverage reports, we go 100% by what’s in the file, so line-level exclusions (vs file-level) would have the intended effect.
I’m not sure what to do with this. Part of me wants to say “don’t add the error handling until after you’ve added the error”.
This is unfortunately file-level only but still would work as a last resort. The advantage with this is that the developers see the exclusion directly in code instead of need to look at a different properties file. The later could be easily overseen when refactoring happens.
Therefore, I’m still interested to understand if there is a way to provide SonarQube a “coverage.xml” which is then used instead of calculating it with the scanner itself?
Part of me wants to say “don’t add the error handling until after you’ve added the error”.
Same here, but I wanted to check with you anyway to get your perspective. I will discuss once more with the developers.
If you’re doing file-level exclusions, then I’m back to setting the same exclusions on the SonarQube side. I prefer the UI for that, but it can be done in the analysis parameters. That’s not in the file being excluded, but at least that would put it in the project.