We have been trying to report test coverage to SonarCloud using our github actions. We’ve followed your documentation regarding setting up test coverage reporting using dotCover ([Coverage] Troubleshooting guide for .NET code coverage import).
Everything seems to be working and processed by sonarscanner. However it (and every variation we tried) won’t end up in SonarCloud report for the pull request. We’ve also closely checked every step in the troubleshooting guide on your community forums ([Coverage] Troubleshooting guide for .NET code coverage import).
We’ve really tried everything we could find in the documentation and on the community forums but nothing seems to work. Could it be that there is an issue on the side of SonarCloud? Otherwise could you please help us try to find the issue.
I have got a lot of debug information but can’t not share this in the public community because of company policy. We can share it but not publicly.
- Github actions workflow file
- Github run logs (including verbose sonarscanner output)
- The generated testreport html files
It’s indeed in the context of a PR. The github action running dotCover and publishing to sonarcloud doesn’t run in the main branch yet as it’s not working for the PR yet.
Here’s the screenshot of the sonarcloud dashboard showing the 0% coverage.
I would be happy to share logs, github action configuration and the generated reports but I can’t do that publicly.
Here it looks like the coverage is being properly processed because it shows the 85.8% Estimated after merge figure.
The reason you don’t see any other information is that there are 0 new lines in the pull request. So there’s nothing to be covered.
What is the context of this pull request? Do you expect to see changed lines of code (not just property files)?
The pull request indeed just contains the configuration for reporting the test coverage.
It was my understanding that it will display the full coverage percentage. So the reported coverage on a pull request only applies only to the newly added lines? And then the “estimated coverage after merge” is the full code coverage for the entire codebase?
Our intended use case was to also guard for a lowering overall coverage, which is something that could happen when tests are modified.
We get that a lot! We don’t have a great answer today.