5

I want to set up my Jenkins with Cobertura to track code coverage. Unfortunately I can not generate a valid xml.

I'm using:

  • gcovr 2.5-prerelease (r2774)
  • Xcode 4.6.1 Build version 4H512

My project is generating code coverage files correctly, but the report created with gcovr is not useful.

The command I use to generate the report is: 

gcovr -r /Users/Shared/Jenkins/Home/jobs/CodeCoverage/workspace 
--object-directory /Users/Shared/Jenkins/Home/Library/Developer/Xcode/DerivedData/myProject-aooceqwwovrizceerghqvhflcfty//Build/Intermediates/myProject.build/Development/myProject.build/Objects-normal/x86_64 
--exclude '.*Developer.*' 
--exclude '.*Tests.*' 
--xml

This will create me this output: 

<?xml version="1.0" ?>
<!DOCTYPE coverage SYSTEM 'http://cobertura.sourceforge.net/xml/coverage-03.dtd'>
<coverage branch-rate="0.0" line-rate="0.0" timestamp="1364322914" version="gcovr 2.5-prerelease (r2774)">
<sources>
    <source>
        /Users/Shared/Jenkins/Home/jobs/CodeCoverage/workspace/Project/myProject/
    </source>
</sources>
<packages/>
</coverage>

Additional Informations:

If I remove --object-directory and -r and then I execute the command from the derived data directory a valid report is generated. This report can be read from cobertura but can not show any detailed information about the source files.

Trisch
  • 138
  • 10
Giuseppe
  • 6,666
  • 2
  • 20
  • 32
  • I actually resigned for using gcovr. I am using a set of shell scripts to generate the XML. First I run gcov, then I exclude some lines between special comments (I am using CoverStory) and then I generate XML from the first column of gcov output. It is actually very easy, you can also reference the source files in your workspace directly so you can easily view the coverage of files on jenkins. – Sulthan Mar 26 '13 at 18:59
  • 1
    @Sulthan Would it be possible, that you share your scripts? I can't get gcovr to work with files generated by Xcode 5 and I'm looking for a different solution. Thanks! – SAE Nov 06 '13 at 22:18

3 Answers3

3

When working with XCode, I've found that using $WORKSPACE/build as the build directory helps with this problem. This keeps the Derived Data directory out of it, and also neatly keeps my object files in the build directory. It also prevents two builds from interfering with each other.

If using the Xcode build tool, set SYMROOT to $WORKSPACE/build in the Tool's build configuration. If you're building from the command line, set it manually on the command line or in the environment.

Then a gcovr script such as:

/your/path/to/gcovr -r . --object-directory build/YourApp.build/Coverage-iphonesimulator/YourApp.build/Objects-normal/i386 --xml > build/coverage.xml

(your path may vary slightly depending on what you call your build style, etc.)

And finally in the Cobertura config, point at build/coverage.xml, and you should get annotated source when you use the tool within Jenkins.

Should do the trick. I've been really happy with that configuration on our small farm of Mac Minis.

gaige
  • 17,263
  • 6
  • 57
  • 68
  • Your solution is interesting so I tried to apply some changes. When I set a custom path for CONFIGURATION_BUILD_DIR or SYMROOT, xcodebuild generate some files inside the specified folder. These files are just the application and the symbolications informations. Object directory is still under Derived Data. – Giuseppe Mar 27 '13 at 12:43
  • Are you using the xcode plugin or something else to do your xcode build? If you aren't using the xcode plugin, can you add your script for the `xcodebuild` command to the question? There are a number of "downstream" settings that normally place the .o files in the path described in SYMROOT, but many can be changed in the project. – gaige Mar 27 '13 at 12:52
  • xcodebuild -workspace myProject.xcworkspace -scheme myProject-Development clean build BUILD_DIR=/Users/Shared/Jenkins/Home/jobs/CodeCoverage/workspace/Project/build/ TEST_AFTER_BUILD=YES – Giuseppe Mar 27 '13 at 14:31
  • Check your Xcode project configuration. Usually SYMROOT is at the top of all of the BUILD dirs, most notably: BUILT_PRODUCTS_DIR and CONFIGURATION_BUILD_DIR. Everything else should flow down from there. If you can't find anything in your project configuration that looks suspect, pull up the raw log in Jenkins and see if you can variables that are being set during the build process to the locations you're seeing the Object files go. This should provide some clue. – gaige Mar 27 '13 at 14:56
  • Neither BUILT_PRODUCTS_DIR nor CONFIGURATION_BUILD_DIR worked to move derived data directory. I have found a working solution using always absolute paths instead of relative one in the parameter I pass to xcodebuild. In this way I can have a full working report for cobertura. I'm still interested in find a way to have a static Derived Data directory for my jobs, it make everything more reliable. – Giuseppe Mar 27 '13 at 15:42
2

gcovr should be executed from the folder where the .gcda and .gcno files exist. And the root path is the folder where the source files(.c or .cpp) exist.

With this, the command looks like something as shown below.

rr-mac:gcdaFolder$ gcovr -r /path_to_C_sourceFiles/ .

For output html file below command works

rr-mac:gcdaFolder$ gcovr --html -o Filename_rp.html -r /path_to_C_sourceFiles/ .

Note: The dot(.) at the end is mandatory

Rajesh Pappireddy
  • 117
  • 10
1

The gcovr python script does not appear to supports out of source tree builds.

I raised a bug report about this here https://github.com/gcovr/gcovr/issues/61

NickBroon
  • 367
  • 3
  • 13