Using Relative Paths With GCOV Sensor

Must-share information (formatted with Markdown):

  • SonarQube 7.7 Developer Edition, SonarQube Scanner 3.0.3.778, SonarCFamily Plugin 6.2 (build 11201)
  • what are you trying to achieve: Import GCOV reports (using relative paths) into SonarQube
  • what have you tried so far to achieve this: Setting GCOV output to use relative paths. The paths in the scanner log incorporate the value of ‘sonar.cfamily.gcov.reportsPath’ into the path for parsing the source file.

Hello,

I am working on getting GCOV reports submitted into SonarQube and ran into an issue where the GCOV sensor cannot find the source file. We have set GCOV properties to have relative paths, however, the scanner still warns the file has not been analysed.

My sonar-project.properties file looks has the following values:
sonar.sources=src
sonar.cfamily.gcov.reportsPath=coverage/reports

Here is a small snippet of the scanner log:
[2019-06-05T20:19:28.320Z] INFO: Parsing {BASE_DIR}/coverage/reports/AttributeList.cpp.gcov [2019-06-05T20:19:28.320Z] WARN: File not analysed by Sonar, so ignoring coverage: {BASE_DIR}/coverage/reports/src/main/AttributeList.cpp

It took a while, but I got this working using a workaround of copying all GCOV files into the root of the workspace (where SonarQube scanner executes) and modifying my sonar-project.properties to:
sonar.sources=src
sonar.cfamily.gcov.reportsPath=.

This feels like an issue with the GCOV sensor setting its own CWD to {BASE_DIR}/{sonar.cfamily.gcov.reportsPath} instead of ${BASE_DIR} to find the corresponding source file scanned by SonarQube.

Has anyone else had experience with the GCOV sensor and importing into SonarQube?

Best regards,

–Mark

1 Like

Hi @scmbuildguy,

I apologise for the delay. I can confirm that at the moment if the file path is relative it is going to take it to be relative to the folder containing the gcov report, as you managed to understand by yourself.

I am wondering what should be the correct behaviour in such case, it is not necessarily true that the correct directory is the scanner ${BASE_DIR} even if in reality it might have more hits than {BASE_DIR}/{sonar.cfamily.gcov.reportsPath}.

Hi @mpaladin,

Thanks for the response. In my experience with build frameworks, the build output directories are generally siblings to the source directories. We currently use CMake for our C++ build and it currently creates a different directory structure for binaries and test results, which is what I would expect. Whether it is a build framework, such as CMake or Gradle, or an IDE, I don’t usually see source directories under or at the same level as test results and coverage.

The other factor in my thinking, which lead me down the wrong path initially, is the GCOV sensor acts differently than other sensors like Java/JS/PHP, where coverage/test results paths are relative to BASE_DIR, which I think means they use {BASE_DIR}/[sonar.source} to find source paths.

Maybe have two paths to look at {BASE_DIR}/{sonar.cfamily.gcov.reportsPath}, then fall back to {BASE_DIR}/[sonar.source}?

Thoughts?

–Mark

1 Like

Hi @scmbuildguy,

I created a ticket to modify the behaviour in case of relative paths: CPP-2231.

1 Like