Coverage reports is not generating after sonar scan analysis

SonarQube Cloud
, ,
22

@necto Did you see my previous comment?

23

Hi @paulbourelly999 , I’m sorry for the delay in the reply. I’ve seen your message but did not have time to look at it yet. I’ll reply to you once I get a chance.

24

Hi @paulbourelly999 ,

I finally got some time to look into it. You definitely made progress with the log above, now you are generating non-empty coverage.xml in the proper format for each module. Now the trouble is, as indicated in the log that Sonar scanner cannot associate the files described in the coverage reports with the source files of the project. The reason is that the coverage report uses paths relative to a different directory than Sonar scanner:

  • Gcovr sets them relative to the --root or -r parameter, so when you run it with -r . from a module folder, e.g. kafka_clients it takes that as a root, and puts paths like src/kafka_client.cpp to the report.
  • Sonar scanner uses the current directory, which is /home/carma-streets so it gets confused when it reads path src/kafka_client.cpp in the report and sees no src directory in /home/carma-streets.

One way to fix that is to run gcovr from /home/carma-streets and use that as the root. Then, you can filter coverage only for relevant files using --filter argument when you run it for each module, i.e.:

/home/carma-streets$ gcovr --sonarqube kafka_clients/coverage/coverage.xml -s -f kafka_clients/ -r .

Then you’ll need to specify all the coverage.xml files separated by commas in the sonar.coverageReportPaths property, like this:

sonar.coverageReportPaths=kafka_clients/coverage/coverage.xml,message_services/... etc.

Alternatively, you can run gcovr once for all the modules like this:

/home/carma-streets$ gcovr --sonarqube coverage.xml -s -r .

And feed it to Sonar scanner:

sonar.coverageReportPaths=coverage.xml

Note that regardless of the module of a source file, Sonar scanner will associate it with the path relative to the project root (/home/carma-streets) in all the coverage reports you feed it, regardless of the module it belongs to.

Note also, if you are using the generic coverage format with this --sonarqube output, you don’t need to configure the gcov specific paths in your sonqr.properties.

Regarding your question about overwriting gcov files in gcovr 5.0 - I don’t know the answer, but encourage you to experiment :slight_smile:

Let me know if that helps.

26

For completeness, I’ve recently did an experiment, and can confirm that gcovr 5.1 still suffers from this issue. See the attached reproducer archive.
gcovr-repro.zip (1.7 KB)
you can see for yourself how it overwrites the gcov files running from the cov-repro folder:

cov-repro$ mkdir build && cmake -B build . && make -C build
cov-repro$ gcovr -k .

You’ll see 100% line coverage for “src/lib.cpp” in the summary table, but only one branch of myfun is covered in the corresponding lib.cpp#.....gcov file.

27

Thank you for your help. Using your previous comment I was able to finally generate accurate coverage reports for our code. Its unfortunate that gcovr has such unpredictable/incorrect functionality.