SonarCloud coverage difference

SonarQube Cloud
,
1

Template for a good new topic, formatted with Markdown:

  • ALM used - GitHub
  • CI system used - Github Actions
  • Languages of the repository - JS/TS
  • Steps to reproduce
    We have integrated SonarCloud recently and we found that the coverage report mentioned in SonarCloud and Coveralls.io has a huge difference of 20%. Below is the coverage file which we send to both coveralls.io and Sonar.
    assist-coverage-5c106afbdc95856c5e988fb8e3fd256c0d451434.zip

And below is the coverage report of folders from both Coveralls and Sonar

image
image694×508 56.5 KB

image
image2334×850 134 KB

Kindly let us know why there’s a huge difference in Coverage report from both when even the lcov tool shows the coverage as 40.6% same as Coveralls.io

image
image834×224 24.1 KB

3

Hello @Sam-Sundar-Apty,

Happy New Year 2022 and welcome to the SonarSource community. :wave:. I hope you’ll enjoy it.

There can be plenty of reasons why the coverage reported by SonarCloud is different from you other tool.

Before we dig into special cases, let’s look at the most common case:
SonarCloud (or SonarQube) computes the coverage on ALL source files of a project/a directory, whereas often external tools focus on a since language/language family (JS/TS in your case).
So for instance, in your project, if you have HTML or CSS files in any directory (eg admin) SonarCloud computes the combined/aggregate coverage of your JS/TS files and the HTML or CSS files. Since the latter often have 0% coverage, the aggregated coverage reported is lower than the tool reporting on only 1 type of source.

It seems stupid to include CSS or HTML in the coverage calculation. That’s true for this case, but for multi-languages projects where each (or several) language can have coverage it makes sense to include all sources files of the different languages in the aggregated calculation.

How to fix?
When you have source files that you want to exclude from the coverage calculation (for good reasons, for instance CSS and HTML are never covered), you can use the sonar.coverage.exclusions property (see SonarCloud doc), for instance sonar.coverage.exclusions=**/*.css, **/*.html

If, despite this, you still see some discrepancies, then please drill down into directories with different coverage reporting between Coveralls.io/LCOV and SonarCloud and we’ll certainly find which files cause the difference.

Olivier