SonarCloud includes a file for code coverage although it's been excluded

SonarQube Cloud
,
1

  • SonarCloud:

    • ALM used (GitHub)
    • CI system used (Azure DevOps)

  • Error observed - I have excluded a file from being considered in code coverage report. But, sonarCloud still reports uncovered lines in that file. I tried to use /* istanbul ignore if */ on the new lines but sonarCloud ignored that too.

1 Like
2

hello
what language are you analyzing?
could you please share the analysis verbose logs (sonar.verbose=true) with us?

3

@Andrei_Epure - its nodejs/typescript

Sonar appears to be ignoring the .nycrc exclusions and is including files not mentioned in the coverage report. Do you expect this behavior?

I can only find one other mention of an .nycrc file here. Its a few years old and says sonar only relies on the ,gitignore file for exclusions.

4

Hey @StingyJack (and @shettibhagya)

If a file is not mentioned in the coverage report at all, SonarCloud will determine which lines are executable (could conceivably be covered by tests) and report 0% coverage.

This is done for a lot of good reasons – but is primarily targeted for multi-language projects where a coverage report might be supplied for one of those languages but not all of them.

sonar.coverage.exclusions is therefore the best way to exclude entire files from coverage calculation when those files aren’t excluded in the coverage report.

I would expect this to work if the file was mentioned in the coverage report at all (because those lines wouldn’t be listed in the coverage report).

Yes, this means duplicating exclusions set in the .nycrc file (we face a similar issue in .NET with .runsettings files (Code Coverage: exclusions in .runsettings file are ignored · Issue #1487 · SonarSource/sonar-dotnet · GitHub).

5

I added the problem exclusion to the sonarcloud UI’s exclusions list. I’m not a fan of the code churn that comes with the “everything as code” nightmare trend (commit, push, wait for pipelines, repeat, just to fix something external to the code).

It would make more sense that when a project is not multi-language (like the one that prompted this), SonarCloud takes the coverage info given to it for that language as the source of truth and does not discard parts of it that it does not like.

Another way to describe it is that this behavior of SonarCloud is inconsistent from what we can see on our local machine for the project . Locally, our coverage is correct, we create a PR, submit it thinking we are OK, only to find out that SonarCloud thinks otherwise.

SonarLint tries to make the local experience the same as the cloud by getting the project rules. There are plans for making the msbuild scanner also follow the project rules. The experience with coverage should be aligned with those.in one way or another.