Plugin split of code-coverage-api plugin

[uhafner]

Repository URL

https://github.com/uhafner/coverage-plugin

New Repository Name

coverage-plugin

Description

I am splitting the code-coverage-api into a legacy and new part. All old and deprecated code will stay in code-coverage-api, all new code will be moved to this new plugin: coverage. For details see dev mailing list thread.

Description of the plugin:

The Jenkins Coverage Plug-in collects reports of code coverage or mutation coverage tools. It has support for the following report formats:

• JaCoCo
• Cobertura
• PIT

The plugin publishes a report of the code coverage and mutation coverage in your build, so you can navigate to a summary report from the main build page. From there you can also dive into the details:

• tree charts that show the distribution of coverage by type (line, instruction, branch, method, class, etc.)
• tabular listing of all files with their coverage
• source code of the files with the coverage highlighted
• trend charts of the coverage over time

GitHub users to have commit permission

@uhafner

Jenkins project users to have release permission

drulli

Issue tracker

Jira

[jenkins-cert-app]

Security audit, information and commands

The security team is auditing all the hosting requests, to ensure a better security by default.

This message informs you that a Jenkins Security Scan was triggered on your repository.
It takes ~10 minutes to complete.

Commands

The bot will parse all comments, and it will check if any line start with a command.

Security team only:

• /audit-ok => the audit is complete, the hosting can continue 🎉.
• /audit-skip => the audit is not necessary, the hosting can continue 🎉.
• /audit-findings => the audit reveals some issues that require corrections ✏️.

Anyone:

• /request-security-scan => the findings from the Jenkins Security Scan were corrected, this command will re-scan your repository 🔍.
• /audit-review => the findings from the audit were corrected, this command will ping the security team to review the findings 👀. It's only applicable when the previous audit required changes.

Only one command can be requested per comment.

(automatically generated message, version: 1.26.14)

[github-actions]

Hello from your friendly Jenkins Hosting Checker

It appears you have some issues with your hosting request. Please see the list below and correct all issues marked Required. Your hosting request will not be approved until these issues are corrected. Issues marked with Warning or Info are just recommendations and will not stall the hosting process.

• ⛔ Required: You must specify an <scm> block in your pom.xml. See https://maven.apache.org/pom.html#SCM for more information.
• ⛔ Required: The 'artifactId' from the pom.xml (coverage-parent) is incorrect, it should be coverage ('New Repository Name' field with "-plugin" removed)
• ⛔ Required: Please specify a license in your pom.xml file using the <licenses> tag. See https://maven.apache.org/pom.html#Licenses for more information.

You can re-trigger a check by editing your hosting request or by commenting /hosting re-check

[NotMyFault]

https://github.com/uhafner/coverage-plugin/blob/8cbba23f7d21511762db620ee0a1bb1097d22231/pom.xml#L7

Can you actually do that? 👀

[uhafner]

Yes, this works in all my plugins. I have a parent module that itself has no version. Only the plug-in has a version. The hi tests do not have a version, too.

[NotMyFault]

/hosting host

[NotMyFault]

/hosting host

Ok, that's a good one, hosting failed because https://github.com/jenkinsci/coverage-plugin exists, and you want to have your plugin under jenkinsci/coverage-plugin 😄

If nobody objects, I'd rename the existing jenkinsci/coverage-plugin repository, freeing the repository namespace and host the plugin manually.
Given, GH handles renames with redirects, we don't break existing links if there are any.
It's worth noting that the existing coverage plugin is almost 15 years old, has no releases, and is considered abandoned.

Edit: The repository has been renamed to https://github.com/jenkinsci/hudson-coverage-plugin, don't wonder why the links above return the intended result by now.

[uhafner]

I wasn't aware that the same plugin name has been used before. I think it is ok to reuse the ID as the old plugin has been archived already.

[MarkEWaite]

I wasn't aware that the same plugin name has been used before. I think it is ok to reuse the ID as the old plugin has been archived already.

I think it is unwise to reuse the plugin identifier because it may confuse systems where the user has not yet removed the old plugin. Plugin identifiers tend to be assumed to be unique in many places. I think it is best to not risk discovering unexpected locations where reuse of a plugin identifier.

[timja]

I think it is unwise to reuse the plugin identifier because it may confuse systems where the user has not yet removed the old plugin. Plugin identifiers tend to be assumed to be unique in many places. I think it is best to not risk discovering unexpected locations where reuse of a plugin identifier.

The old plugin was never released, hence safe to re-use