I’m having an issue with our PR decoration. The code coverage on new code isn’t displayed. This is problematic if we want to enforce our quality gate on each PR.
Kudos, SonarCloud Quality Gate passed!
Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities (and Security Hotspot 0 Security Hotspots to review)
Code Smell A 0 Code Smells
No Coverage information No Coverage information
No Duplication information No Duplication information
When taping on “No coverage information”, SonarCloud says :
“Details are not available for estimated measures.”
The “No Coverage information” in the summary comment implies that the coverage report file did not get processed for some reason. Please review the logs of the scanner, it should mention about importing the coverage report file, and if it failed, and why. Please also review the content of the sonarqube-generic-coverage.xml file.
INFO: Parsing /Users/vagrant/git/sonarqube-generic-coverage.xml
INFO: Imported coverage data for 860 files
INFO: Coverage data ignored for 231 unknown files, including:
/Users/vagrant/git/Pods/FirebaseABTesting/FirebaseABTesting/Sources/ABTConditionalUserPropertyController.m
/Users/vagrant/git/Pods/FirebaseABTesting/FirebaseABTesting/Sources/FIRExperimentController.m
/Users/vagrant/git/Pods/FirebaseABTesting/FirebaseABTesting/Sources/FIRLifecycleEvents.m
/Users/vagrant/git/Pods/FirebaseABTesting/FirebaseABTesting/Sources/Protos/developers/mobile/abt/proto/ExperimentPayload.pbobjc.m
/Users/vagrant/git/Pods/FirebaseCore/FirebaseCore/Sources/FIRAnalyticsConfiguration.m
INFO: Sensor Generic Coverage Report (done) | time=513ms
For me, that doesn’t indicates any error. I would also add that I can easily see the code coverage when I connect on sonarcloud.io.
I can also see that my quality gate is failing because the code coverage is less than expected on new code (exactly what I want to enforce on GitHub). And if I display the activity for a pull request on sonar, it only displays an estimated code coverage after merge.
Thanks for your help as this is kinda a deal breaker for us.
Not an error, but the generic coverage report contains 231 files that cannot be found in the project. This raises some relevant questions:
why are there files in the report that don’t match the filesystem
can we be sure the files where we expect coverage are correctly imported, and not one of the unknown ignored files
The latter is a bit hard to confirm, because the output only shows 5 of the ignored files, not the complete list (not even in debug mode).
I suggest the following to inspect the content of the sonarqube-generic-coverage.xml file:
find the paths of files where you expect to see coverage on SonarCloud. If there are no <file ...> entries for them, they cannot be visible on SonarCloud.
make sure the paths are correct:
if absolute path, do they really exist in the filesystem at the time of the analysis?
if relative path, do they really exist relative from the working directory of the scanner process?
It may be useful to craft the XML file by hand, removing <file ...> entries that are not relevant for the pull request. That way, the message about “Coverage data ignored …” will show 5 relevant examples.
Something that looks strange in your first post is the “No Coverage information” and “No Duplication information” messages. Normally, when there is any code difference from the base branch of the PR, the message would say some percent of coverage and duplication, for example 0%. And by “any code difference”, I don’t mean simply a non-empty git diff with the base branch, but code as configured by scanner parameters such as sonar.sources.
Please check the Code tab of the PR on SonarCloud, and see which files are there. If the files you expect are not there, that will also explain why coverage is not there. If that’s the case, then the problem maybe configuration of the files to analyze by the scanner (see detailed documentation on our Narrowing the focus page).
I hope the above will help, let us know how it goes!