Coverage not shown correctly in sonar

SonarCloud
1

We see the coverage beign generated in our local machine dosent match with the coverage shown for the file in sonar.We are using codebuild where we run testcases and then get coverage.The coverage results are then sent to sonar.
We are using the below command in our buildspec.yaml file to send coverage results to sonar :asterisk:

sonar-scanner -Dsonar.organization=$SONARCLOUD_ORG -Dsonar.projectKey=$PROJECTKEY -Dsonar.sources=shared/src -Dsonar.tests=shared/src -Dsonar.test.inclusions=/test/,/*.test.ts,/*.spec.js -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=$SONARCLOUD_TOKEN -Dsonar.scm.disabled=true -Dsonar.javascript.lcov.reportPaths=shared/coverage/lcov.info

2

Can you share a specific example where the coverage doesn’t match?

3

Hi Colin, here’s a specific example I’m seeing. I have tests written for a file named map.ts and I can see full test coverage when running jest locally. But in SonarCloud it shows no test coverage. Thanks.

image
image1838×620 61.4 KB

image
image2584×982 165 KB

4

Thanks.

Is the report you’re showing a screenshot of being generated with local coverage information, or on AWS CodeBuild? I would suggest double checking the coverage file being produced on AWS CodeBuild to see if it matches locally.

5

Hi Colin, yes we’ve confirmed that the lcov files that are produced locally match the lcov files produced on AWS CodeBuild. But SonarCloud is still reporting no coverage for these methods. What do you recommend trying next?

6

It would be great if you could create a small reproducer project where the behavior can be reproduced.

7

Colin, can we share our SonarCloud project with you directly? The issue is pretty obvious there.

8

Hey there.

There’s more at play here – including the coverage report that is produced by the project. It would be really helpful for you to provide a small reproducer project.

9

Hi Colin we believe we’ve identified the issue. Our project has multiple folders which each have their own node project. We generate a coverage report for each folder and provide the list of lcov files as input to SonarCloud. So the parameters we’re actually passing to sonar-scanner are the following:

-Dsonar.sources=api/src,shared/src,lambdas/src,client/src
-Dsonar.tests=api/src,shared/src,lambdas/src,client/src
-Dsonar.test.inclusions=**/__test__/**,**/*.test.ts,**/*.spec.js
-Dsonar.javascript.lcov.reportPaths=api/coverage/lcov.info,lambdas/coverage/lcov.info,shared/coverage/lcov.info,client/coverage/lcov.info

We have some source files that have the same path under each respective folder root. For example:

  • shared/src/lib/map.ts
  • client/src/lib/map.ts

It appears the coverage reports are conflicts for these files with similar paths when SonarCloud is joining them on their side. Can this be handled correctly? Thanks for your support.

10

Hey there.

Is it possible for you to generate the absolute paths instead of the relative paths when generating the coverage reports (at least, enough of the path to let SonarCloud differentiate between them)? You’re right – for two coverage reports that both include shared/src/lib/map.ts, SonarCloud won’t be able to differentiate the files.