feat(jenkins): add metric parameter support for apiv4 coverage plugin [Jenkins]

[ashif323]

What

Closes #11689

Adds support for the new Jenkins Coverage Plugin (io.jenkins.plugins.coverage) by extending the existing apiv4 format with an optional metric query parameter.

Why

The apiv4 format previously only supported line coverage. The new Jenkins Coverage Plugin exposes multiple metrics (branch, instruction, method, module, file) that users may want to display as badges.

How

• Added metric query parameter to queryParamSchema (valid values: line, branch, instruction, method, module, file, default: line)
• Updated apiv4 schema to accept all metrics as optional fields
• Updated apiv4 transform to use the selected metric
• Updated handle method to pass metric to transform
• Updated description to mention the new Coverage Plugin
• Added mocked tests for default metric and branch metric

Example

[github-actions]

	Messages
📖	✨ Thanks for your contribution to Shields, @ashif323!

Generated by 🚫 dangerJS against 7642e82

[PyvesB]

Hello @ashif323 👋🏻 Do you have an example of live Jenkins job that uses the new plugin?

[ashif323]

Hi @PyveB 👋

I don't have a live Jenkins job available right now. Could you guide me on what would be the best way to provide a working example? I'm happy to set one up if needed to get this PR over the line!

[PyvesB]

I don't know how to get a working example, that's why I asked a couple of times on the linked issue.

How did you validate these changes are correct and will work?

[ashif323]

Hi @PyvesB 👋

I validated the changes by:

1. Reading the Jenkins Coverage Plugin API docs and the existing apiv4 implementation
2. Mocking the API response in tests based on the documented JSON structure
3. Running the existing test suite to ensure nothing was broken

I understand this isn't the same as a live Jenkins job. If the maintainers feel a live example is required before this can be merged, I'm happy to look into setting up a demo Jenkins instance with the Coverage Plugin installed.

Alternatively, if there's a public Jenkins instance already using this plugin that we could reference, that would also work. Would that be acceptable?

[jNullj]

It's always better to have a live example, and I don't think we can add code before testing it at least once with a live example.
Using public instance is ok for most tests as we don't make a big amount of calls here, you can also see we use existing public instances in some tests. we don't have to create our own public service for all test cases.

[ashif323]

Hi @jNullj @PyvesB 👋

I've spent time searching for a public Jenkins instance using io.jenkins.plugins.coverage with accessible API endpoints but haven't been able to find one:

• ci.jenkins.io coverage endpoints return {}
• Apache builds (builds.apache.org) use different coverage tools
• No other public instances found

It seems the new Coverage Plugin isn't widely deployed on public Jenkins instances yet, which makes it very difficult to provide a live example.

Given this blocker, I have two options:

1. Close this PR until a public instance is available
2. Set up a minimal public Jenkins demo instance myself

What would you recommend? I don't want to keep this open indefinitely if a live example is a hard requirement.

[PyvesB]

I'll try to look for some instances in the coming days. Travelling at the moment, so a little slow to respond. :)

[PyvesB]

From what I can tell, https://jenkins.mm12.xyz/jenkins/job/nmfu/job/master already uses the new Jenkins code-coverage plugin. As I hinted at in #11689 (comment), our badges already support the latest and greatest Jenkins coverage plugin. I'm still unsure why @markshep and @martontorner-cs claimed it wasn't supported, perhaps we're missing something here.

@ashif323 I'd be happy for us to enhance the existing badge with metric parameter support, we can just replace the newly-added tests with one live test that exercises the metric=branch case. :)

[martontorner-cs]

I looked into the issue deeper and it turns out that both sides are correct. The basic case is in fact correctly supported on your side. The issue is if you assign an ID (https://www.jenkins.io/doc/pipeline/steps/coverage/) to the recordCoverage step, it will also change the URL of the report (e.g. in our case we wanted to separate multiple reports, and one of them was https://[domain]/job/[redacted]/job/[redacted]/job/master/132/tests/api/json that was in my original comment), which is not supported by your implementation that always uses the .../covarage/api/json (in our case the https://[domain]/job/[redacted]/job/[redacted]/job/master/132/coverage/api/json) path to look for the coverage report. In the future it might be useful to make this parametrizable.

Sorry for the bit of confusion that this caused.

[PyvesB]

In light of the comment above, I'd be in favour of starting with this:

@ashif323 I'd be happy for us to enhance the existing badge with metric parameter support, we can just replace the newly-added tests with one live test that exercises the metric=branch case. :)