Yes, it largely stems from the assumption that sonarsource makes that there will be a single, unified coverage report per file with the gcov report. If you use multiple programs to cover a file (say a unit test, then a function test) only one set of results is chosen despite there being multiple sections in the gcov document.
The process to actually get something working was pretty complex and not documented well at all.
Things that didn’t work
- The gcov plugin can only process 1 of many blocks, silently ignoring the others. It also requires the user to deal with converting the gcno & gcda files into meaningful gcov files (not as trivial as you’d think) when you have multiple runs & a c file is included by another c file to work around
- Using gcov-tool to merge reports together didn’t work for an unknown reason, but it had the same issues where some coverage reports were just randomly dropped.
- Using the jacoco coverage didn’t work.
- sonar.coverage.xmlReportPaths didn’t work.
- sonar.coverage.ReportPaths didn’t work.
The one thing that did work
From the build directory (using cmake) this command properly gathers the report:
gcovr --sonarqube coverage.xml -r …
With the instruction to include the report in my .sonar-project.properties file:
But it’s amounted to a bunch of guesses & I kept trying random versions to try to get one that works. The documentation acts like
sonarqube, but the parameters for each are similar… ?