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?
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}.
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}?
(SonarQube developer edition 8.4)
I have a similar issue: In a normal scenario uploading gcov results to sonarqube works pretty well. But in a bit different scenario, I get the warning that sonar decided to not analyze. But, I would also like to know what is the error in order to fix. Right now is a kind of hit or miss.
" 14:23:24.194 INFO: Sensor gcov [cpp] 64714:23:24.196 INFO: Parsing /builds/mydir/build/Linux/Debug/gcov/helloworld.c.gcov 64814:23:24.216 WARN: File not analysed by Sonar, so ignoring coverage: /rst1/ci_cd/GitLab/runner/builds/0/mydir/src/lib/helloworld.c
"
Scenario:
running tests with code coverage, generating .gcov files, referring this path to sonar worked for me in a normal scenario: all paths are on the same machine and executed on the same machine. Paths provided in sonar-scanner.properties are relative to this file.
Scenario2:
I generate the gcov results on a machine and download those as artifacts to another machine.
So if I look at the gcov file: the source is still pointing to the absolute remote source path.
Then I run the sonar scanner where I downloaded these artifacts. which give me the error as shown above.
Directory structure:
Downloaded files:
/builds/mydir/build/Linux/Debug/gcov/*.gcov
builds/mydir/sonar-scanner.properties
I am not expecting a solution to this. But, I would like to know more details about the error. Can I somehow make sonar-scanner to report what is the actual error?