gcovr with jenkins doesn't work

Question

I am trying to produce code coverage report using gcovr from Jenkins but to no avail, it doesn't produce the result but if I run it from terminal, it works fine. here is the command i am executing thru jenkins to generate the same :

gcovr -r /path/to/sourcefiles --object-directory=/Users/testinganywhere1/pathtogcdafile -x -b -e /Developer 1> html/coverage.xml 2>/tmp/Error.txt

If i run the same through terminal it works grt!

thanks for the help!

PS: I am running jenkins on master machine and instructing it to execute the job on slave machine.

Answer 1

You must first go to the object directory before executing it

 cd /Users/testinganywhere1/pathtogcdafile;
 gcovr -r /path/to/sourcefiles --object-directory=/Users/testinganywhere1/pathtogcdafile -x -b -e /Developer 1> html/coverage.xml 2>/tmp/Error.txt

Answer 2

For anyone else with this issue, for me, this turned out to be a difference in the path that is set when running as the Jenkins user from command line vs actually running through Jenkins.

So try running "echo $PATH" in both Jenkins and manually from command line and then compare the two.

Answer 3

I got this running for Jenkins and SonarQube recently. The configuration was aimed at getting the data imported into SonarQube via the community CXX Plugin, but the coverage files can also be used by the Cobertura plugin for Jenkins.

The problematic part was getting the source filenames correct in the XML report. For SonarQube, they are expected to be relative to the "project root", which is wherever the 'sonar-project.properties' is located, or SonarQube's "runner" is invoked from. In our case this wasn't the same as the root of the workspace.

The version of 'gcovr' we needed was the current HEAD revision (2017-06-14), as the released 3.3 version didn't work for us. In addition, I had to normalise the filepaths in gcovr's 'process_gcov_data' function, after it had been determined, but before filtering was applied. For the version we pulled, the following was added as line 524:

fname = os.path.normpath (fname);

'gcovr' has a limitation that it will only find files in folders between the root directory and the object directory - a one-dimensional search. However, files outside this line can occur where the gcov data contains a relative filename specification, such as header files. I raised a ticket with gcovr to search subdirectories of the roots instead, but I wouldn't hold my breath.

Our call to 'gcovr' was then:

cd <project-root> && gcovr         \
    <object-directory>             \
    --root=<project-root>          \
    --xml-pretty                   \
    --exclude-unreachable-branches \
    -o <output-xml>

Where <object-directory> is the location containing the object files and the coverage data, and <project-root> is the base of our project. All are absolute paths, and <object-directory> is under <project-root>.

In our case the sources-under-test where in directories between <project-root> and <object-directory> - although I do not like this restriction of'gcovr'.

The <output-xml> then contains Cobertura-format XML coverage with filepaths relative to <project-root>.

These are imported into Jenkins using the Cobertura Plugin. In our case we are using pipeline scripts, and in the "Pipeline Syntax" page the plugin appears as a suboption to the step snippets:

step([
    $class: 'CoberturaPublisher',
    coberturaReportFile: '<output-xml>',
    failNoReports: false,
    failUnhealthy: false,
    failUnstable: false,
    maxNumberOfBuilds: 100
])

Your options may vary, and we specify the file as a wildcard.

The coverage then appeared on the project's page within Jenkins, both as a summary graph, and a link to 'Coverage Report' which seems accurate.

The XML format contains a <source> tag which lists the absolute path of the <project-root> used by Jenkins. It would be preferable if this was relative to the workspace, but thats for another day. Filenames are then relative to this <source> location.

The SonarQube plugin is a pain because it ignores the <source> tag, and requires that filenames are simply relative to the <project-root> (where sonar runner was invoked).

I'm now showing a mightly 1% coverage on the project I'm using to workout this template - but its the data path thats important at the moment...

Answer 4

SETTING THE JENKINS PATH TO THE RIGHT GCOV.EXE IS NOT ENOUGH!

You have to add another run time option to ensure that the python script has an idea of where the gcov.exe is as it pawns new tasks.

So the additional command line option that worked was:

--gcov-executable (PATH TO THE GCOV EXECUTABLE THAT RELATES TO YOUR INVOCATION OF GCC)

The GCOVR docs do make it clear that you need to run the correct version of the gcov.exe in order for gcovr to work correctly. What isn't clear is that on Jenkins setting the Jenkins PATH to the correct gcov.exe location is not enough.