JenkinsCoverage from Unified Coverage Plugin

[calebcartwright]

:clipboard: Description Jenkins has a number of plugins available for code coverage information. We currently support coverage badges for the JaCoCo and Cobertura plugins, but not the newer Unified Coverage Plugin

Refs #3761

:link: Data

• Is there a public API? Yes
• Does the API requires an API key? Same as other Jenkins badges (no for public instances, yes for private instances)
• Link to the API documentation: https://github.com/jenkinsci/code-coverage-api-plugin#rest-api

:microphone: Motivation Allow users that leverage the coverage plugin to get coverage badges from Shields (without requiring them to use a different plugin)

[PyvesB]

Note that Cobertura itself relies on the Code Coverage API plugin (though I don't think this is the case for the JaCoCo plugin), so we can probably replace the Cobertura specific processing with this new implementation and possibly put a redirector in place.

[henryborchers]

JaCoCo was the first supported format by the Code Coverage API. https://github.com/jenkinsci/code-coverage-api-plugin#embedded

[PyvesB]

JaCoCo was the first supported format by the Code Coverage API. https://github.com/jenkinsci/code-coverage-api-plugin#embedded

Indeed, but I believe that you can use the JaCoCo plugin without having the Code Coverage API plugin installed. Therefore we'll still have to have badges that integrate with the JaCoCo API and the Code Coverage API separately. On the other hand, the Code Coverage API plugin is a dependency of the Cobertura plugin. 😉

[PyvesB]

Anyone know of any public Jenkins instance that has the Code Coverage API plugin installed? We use jenkins.sqlalchemy.org for our Cobertura tests, but unless I'm mistaken it's running an older version of the Cobertura plugin, therefore Code Coverage API is not a dependency there.

Same for builds.apache.org.

[calebcartwright]

Anyone know of any public Jenkins instance that has the Code Coverage API plugin installed?

Unforunately I don't. There's obviously tons of Jenkins instances out there, but it's always tricky finding one that has the plugins, job, etc. needed 🤷‍♂

I did come across this page the last time I was looking for some Jenkins instances to update the tests. There's a lot of dead links in there unfortunately but I did find it a helpful resource.

https://wiki.jenkins.io/pages/viewpage.action?pageId=58001258

[calebcartwright]

Here's one (at least I think 😄): https://jenkins.library.illinois.edu

@henryborchers I found that from your project that you referenced in #3761. Do you know if that's a relatively available/stable Jenkins instance?

[henryborchers]

Not sure what you’re asking. It’s publicly accessible to view but you are not going to be able to run your own jobs. It’s really for our own development work.

[calebcartwright]

I was not asking if we could use it to run our own workloads 😉. We just need a public instance to look at for developing and testing Shields integration

[henryborchers]

Then you should be fine.

[PyvesB]

Here's one (at least I think smile): https://jenkins.library.illinois.edu

Okay thanks, will have a look sometime over the weekend!

[PyvesB]

As far as I can tell, the REST API documentation's for the Coverage API plugin is pretty much inexistent, it's simply a list of four endpoints. The one we're interested in is probably the following: …​/{buildNumber}/coverage/…​/result/api/\{json|xml\}

What's troubling me is the second ... placeholder. After a bit of digging around, I believe its value is dependent of the plugin that integrates with the coverage API:

• jacoco__jacoco
• istanbul__coverage_xml
• cobertura_xml
• ...

As you can see, these aren't consistent nor easily guessable. I haven't managed to find any documentation about this parameter either, I only got these examples by navigating through various GitHub issues.

In the case of the jenkins.library.illinois.edu instance, it seems possible to omit this extra parameter (https://jenkins.library.illinois.edu/job/OpenSourceProjects/job/Speedwagon/job/master/1120/coverage/result/api/json?depth=1). Is it due to the way the integration with the Coverage API plugin is built in this case or is the parameter always optional? Does omitting it give you some sort of aggregate instead? @henryborchers do you have a better understanding on how this works?

[PyvesB]

I've just raised an issue on the plugin's repository to get some more information (https://github.com/jenkinsci/code-coverage-api-plugin/issues/126), as we're not making much progress here.