cobertura-plugin | Jenkins cobertura plugin | Plugin library

Ok I've found reasons why I had a problems with this plugin.

1. xml from openCppCoverage is just correct. No changes are needed here to make it work (as far as sources are there where pdb file points to). Sources outside Jenkins workspace are not the problem here. When I copied executable from build machine to test machine, then run tests with openCppCoverage and copied result back to build machine it is just fine.

2. In job configuration any user which supposed to view code coverage has to have access to Job/workspace in security section. In my case I've enabled this for all logged in users. This covers last bullet point of error message.

3. Most important thing: build must be successful. I mean form beginning to the end. Doesn't meter if step containing call to cobertura plugin was successful. If any step (even in the future step) fails then cobertura will not show code for this coverage run. In my case build job was failing since one of tests was timing out. This was caused by openCppCoverage overhead which slows down tests by factor 3. My script was detecting timeout and killing one of tests.

I discovered that not successful build was a problem by accident. During experiments I noticed two cases when cobertura has shown source code:

• I've rerun job and removed all steps but one responsible for publishing coloratura results
• I run whole job such way it run a single test case which passed

Not sowing coverage if build is not successful is reasonable (if test failed then most probably wrong branch of code has been taken), but UI should indicate that in different way.

This is great example how it is important to report errors to user with precise details what went wrong and why. I wasted at least whole weak to figure out what is actually wrong which bullet point of error message is actually my case. In fact error message from plugin doesn't cover all reasons of not showing the code.

I will file report that plugin should give better explanation what went wrong.

I was able to find why I couldn't upload any files: In my file Resources.groovy, I had :

My JAVA_HOME was set to use Java10, forcing maven to use Java8 resolved the issue.

Cobertura does not currently support Java 1.8.

cobertura-maven-plugin does not support Java 1.8 properly #21

ParseException JavaNCSS got an error while parsing the java file #176

The latter has been an issue since 2014, so I don't expect it to ever be fixed.

JaCoCo might suit your needs.

Your test is causing the issue. You are trying to scan the Spring packages which contains a lot of Autoconfiguration and other Configuration classes which the context is trying to load. You should never do this.

All you should need to do for your test is this add

The Cobertura Maven Plugin doesn't provide a way to customize the location of the sources. By default, it then looks into the Maven standard folder, which is src/main/java. Since your Groovy classes are located inside src/main/groovy, they are not found.

There are 2 solutions depending on your project:

• Add those sources to the project with the help of the build-helper-maven-plugin:add-source Mojo:

Just like the error message tells you.

You have declared a dependency on net.sourceforge.cobertura:cobertura:2.0.3 in your root project (as it is not added explicitly, I'd guess the Gradle cobertura plugin adds it implicitly, its documentation should probably tell so) but you do not have any repository defined for your root project. You only declared repositories for the buildscript (to resolve Gradle plugins and stuff) and for all sub-projects in the subprojects closure. Define the repository also for the root project, either separately, or by using allprojects closure and your build should work fine, at least in this regard.