Code coverage analysis data ignored for source files

SonarQube Cloud
, ,
1
  • ALM used: GitHub
  • CI system used: GitHub
  • Scanner command used when applicable
    sonar-scanner -X -Dsonar.cfamily.threads=4 -Dsonar.cfamily.build-wrapper-output=build_wrapper_output_directory -Dsonar.login=${{ secrets.SONAR_TOKEN }}"
  • Languages of the repository
    Cfamily
  • This concerns a private sonarcloud project
  • Error observed:
    I am facing a problem with generating a coverage report for our cfamily repository. I am building the job with build-wrapper - which seems to work for static analysis of the project.
    Anyway when sonar-scanner is accessing the coverage files generated by ceedling utils:gcov - gcovr is generating three coverage.xmls, one for each sub-project with following command, docker image is used to trigger all these commands.

ceedling utils:gcov
Link to ceedling gcovr tool guide: https://github.com/ThrowTheSwitch/Ceedling/blob/master/plugins/gcov/README.md

I am facing a following error for some reason - source files not are not found.
Project is configured so that there is a main project (git repository) and underneath few sub-projects, sub-project folders are having their own unittests -folders.

021-05-25T13:17:21.5359201Z 13:17:21.535 INFO: Sensor Generic Coverage Report
2021-05-25T13:17:21.5367307Z 13:17:21.536 INFO: Parsing <path1_to_gcovr_results>/coverage.xml
2021-05-25T13:17:21.6502279Z 13:17:21.644 INFO: Imported coverage data for 0 files
2021-05-25T13:17:21.6507125Z 13:17:21.650 INFO: Coverage data ignored for 30 unknown files, including:
2021-05-25T13:17:21.6509655Z <folder1>/file1.c
2021-05-25T13:17:21.6514832Z <folder2>/file2.c
2021-05-25T13:17:21.6521926Z <folder2>/file3.c
2021-05-25T13:17:21.6522499Z <folder2>/<folder2_1>/file4.c
2021-05-25T13:17:21.6523109Z <folder2>/<folder2_1>/file5.c
2021-05-25T13:17:21.6527814Z 13:17:21.652 INFO: Parsing <path2_to_gcovr_results>/coverage.xml
2021-05-25T13:17:21.6831272Z 13:17:21.682 INFO: Imported coverage data for 0 files
2021-05-25T13:17:21.6832730Z 13:17:21.682 INFO: Coverage data ignored for 26 unknown files, including:
2021-05-25T13:17:21.6834270Z <file1>.c
2021-05-25T13:17:21.6834684Z <file2>.c
2021-05-25T13:17:21.6835201Z <file3>.c
2021-05-25T13:17:21.6835551Z <file4>.c
2021-05-25T13:17:21.6836062Z <file5>.c
2021-05-25T13:17:21.6837542Z 13:17:21.682 INFO: Parsing <path3_to_gcovr_results>/coverage.xml
2021-05-25T13:17:21.6893210Z 13:17:21.688 INFO: Imported coverage data for 0 files
2021-05-25T13:17:21.6894058Z 13:17:21.689 INFO: Coverage data ignored for 3 unknown files, including:
2021-05-25T13:17:21.6894815Z <folder1>/<file1>.c
2021-05-25T13:17:21.6896653Z <folder1>/<file2>.c
2021-05-25T13:17:21.6897206Z <folder1>/<file3>.c
2021-05-25T13:17:21.6898884Z 13:17:21.689 INFO: Sensor Generic Coverage Report (done) | time=154ms

My sonar-project.properties file looks as follows:

sonar.projectKey=<hidden>
sonar.organization=<hidden>
sonar.host.url=https://sonarcloud.io
sonar.sources=<comma_separated_source_file_folders>
sonar.tests=common/unittests/,<folder-2>/unittests/,<folder-3>/unittests/
sonar.exclusions=**/Generated_Source/**/*, common/unittests/,<folder-2>/unittests,<folder-3>/unittests/
sonar.test.inclusions=**/unittests/**/*.h,**/unittests/**/*.c
sonar.coverageReportPaths=<path1_to_gcovr_results>/coverage.xml,<path2_to_gcovr_results>/coverage.xml,<path3_to_gcovr_results>/coverage.xml
sonar.sourceEncoding=UTF-8

  • Steps to reproduce:
    Create a docker image for cfamily code repository
    Build the code by using build-wrapper using docker container
    Run unittests ceedling gcov:all for all projects using docker container
    Create sonarqube report by running ceedling utils:gcov in docker container
    Run sonar-scanner by installing it in the docker container - evaluate coverage page and logs from sonar-scanner.

  • Potential workaround:
    I have not found a workaround for this so far

4

Hi @hnrhonkala88 ,

in order to help me with understanding what happens would you be able to share the following:

  • sonar-scanner debug logs (with sonar.verbose=true property specified)
  • one of the coverage.xml files
  • the GitHub action file

I can send you a private message where you can share privately if you wish.

5

Could you explain how you are running gcovr? When gcovr creates a SonarQube report, it normalizes most file names to be relative to the --root directory.

When Sonar later imports these report, the paths in each report must be interpreted relative to the report’s root directory. It might be that there is a mismatch here, especially since you have multiple reports that might have different root paths.

I’m a gcovr maintainer so maybe I can help from that end, but I have no idea how sonar-scanner works.

6

Hi!

Yes, this issue described by latk was a root cause for the problem. I am running “ceedling gcovr” in the sub-folders of the project and therefore the filenames were relative to there.

@latk Do you have some hints how I could configure gcovr to have paths correctly configured to be relative to my git repository root folder without need to touch them afterwards by using sed?

@mpaladin Could you please write me a private message, I have another question too which is not yet published on this forum.

7

Hi @hnrhonkala88 ,

if you have another question feel free to open a new topic, no need for a private message.

8

I’m not familiar with how Ceedling exposes the various gcovr command line options, but the general approach would be to set the gcovr --root to your top-level directory for all reports. This root has many subtle effects on how gcovr works, including determining how paths are shown in the report. Other effects that might be impacted:

  • The --root also acts as a default filter for determining which coverage data is included in a report. The --filter and --exclude options can be used to override this. Likely, you need a --root to the top-level and a --filter for the subproject. See Using Filters in the gcovr 4.2 manual for details.

  • The --root is unfortunately also used in some heuristics to find the correct working directory from which gcovr will run gcov. This could lead to problems if you are using a separate build directory, as is common with CMake. Maybe everything turns out fine but if there are problems, then sed is probably your best bet right now. Sometimes the --object-directory option helps since it overrides heuristics normal.

9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.