generated xml invalid paths for Cobertura report

Issue #526 resolved
Dirk Thomas created an issue

When generating the coverage report as a .xml file the source + filename does not add up to a correct path. As a result the Jenkins Cobertura plugin can't show the source of each module:

I have created a Jenkins job to reproduce the issue:

The steps are fairly simple:

cd  /tmp
python3 -m venv venv
. venv/bin/activate
pip install coverage mock nose
git clone
cd ament_package
python3 -m nose --nocapture --with-coverage --cover-package ament_package --cover-xml --cover-xml-file coverage.xml

The resulting coverage.xml file contains a source entry pointing to the Python module .../ament_package/ament_package. The class entries have a filename like ament_package/ and a name ( The problem is (as far as I can see) that the source + filename doesn't add up to a correct path. Basically the package name folder is repeated in both. The correct full path should be .../ament_package/ament_package/

The full console output can be found here and the full coverage.xml file here.

Comments (27)

  1. Loic Dachary

    I've been able to run the reproducer and obtain the XML file that matches your description. I'm not able to reproduce the problem because I don't have access to a jenkins running the cobertura plugin. Could you confirm that running without the --cover-package ament_package generates an XML file with links to sources that are correct ?

    python3 -m nose --nocapture --with-coverage --cover-xml --cover-xml-file coverage.xml

    The sources element does not contain the extra package in this case. I've not been able to find the documentation for the expected content of the XML file. The DTD is validated and correct but only set the requirements for the elements and the attributes, not their content.

  2. Dirk Thomas reporter

    I just ran a third build without the argument ( The result is "interesting". The breakdown list contains multiple rows - the relevant ones are "." and "ament_package". For the second one the sources are shown correctly. For the first one the problem is still the same. I think the build no. 2 (with the argument) only showed the "." entry which didn't work in.

    I hope that helps...

  3. Loic Dachary

    @dirk-thomas I noticed your test run is using coverage 3.4. Would it be possible to upgrade to coverage 4.3.1 and verify if the issue still exists ?

    Installing coverage-3.4 script to /var/lib/jenkins/jobs/test_coveragepy/workspace/venv/bin
  4. Dirk Thomas reporter

    I was surprised since it installs the package from PIP. Therefore I added a pip freeze call to the latest build ( It shows that it installed coverage==4.3.1. So it looks like that the two lines during the installation are kind of misleading:

    Installing coverage-3.4 script to /var/lib/jenkins/jobs/test_coveragepy/workspace/venv/bin
    Installing coverage3 script to /var/lib/jenkins/jobs/test_coveragepy/workspace/venv/bin
  5. Loic Dachary

    @dirk-thomas thanks for checking. And the XML file consistently displays the coverage version as well. It's not a version mismatch then.

    <coverage branch-rate="0" line-rate="0.3515" timestamp="1483719279629" version="4.3.1">
  6. Loic Dachary

    @dirk-thomas could you please try to run coverage run -m nose ; coverage xml instead of python3 -m nose --nocapture --with-coverage --cover-xml --cover-xml-file coverage.xml ? The result is different when I run it locally. If it displays correctly we will know that the nose coverage plugin does something that is not right. If the output does not display well... we will be even more confused ;-)

  7. Loic Dachary

    @dirk-thomas interesting. Do you know of a project successfully using the Cobertura Coverage Report jenkins plugin with ? It would be helpful to see how it looks. I'll analysing this new run and try to guess what's going on.

  8. Loic Dachary

    @dirk-thomas is there a way to see which version of the cobertura coverage report plugin you are using ? I'd like to read the sources to get a sense of what it expects.

  9. Loic Dachary

    @dirk-thomas could you please try a run with coverage run --source=ament_package -m nose ; coverage xml ? That will change paths to be relative instead of absolute. It should not change anything in theory. Except if jenkins moves the directory around and the absolute paths is no longer valid. If, as I suspect, this change does not improve things, at least it will tell us the problem is unrelated to absolute vs relative path names.

  10. Ned Batchelder repo owner

    @dirk-thomas any newer information on this? I'm not sure what change you're looking for in

  11. Dirk Thomas reporter

    I don't have any newer information on this. In the current state I still don't see the sources (instead: "Source code is unavailable").

  12. Ned Batchelder repo owner

    OK, the nose plugin is doing something weird. The coverage xml command produces the correct results. I'll take a look at what the plugin is doing and see if there is a way to have both work.

  13. bmerry

    I can confirm that using coverage xml after running the nose plugin works for me (with the Jenkins Cobertura plugin), while using nosetests with --cover-xml generates broken paths.

    The nose plugin actually generates nicer filenames e.g. mypackage/ instead of venv/lib/python2.7/site-packages/mypackage/; but unfortunately the plugin sets to the source to venv/lib/python2.7/site-packages/mypackage instead of venv/lib/python2.7/site-packages, so the combined paths are wrong.

  14. Dirk Thomas reporter

    I don't think that the referenced commit fixes this. The problem described in this ticket is not related to files. The problem is that the two pieces of information (source and filename) do not add up to a correct path. Therefore I think this should be reopened.

  15. Ned Batchelder repo owner

    This also happens without the nose plugin if you use source = ament_package in the .coveragerc file, but not if you specify it on the run command line! :(

  16. Log in to comment