Adopt Copy Data To Workspace Plugin

[jimmyleocn]

Link to GitHub repository

https://github.com/jenkinsci/copy-data-to-workspace-plugin

When modifying release permission

List the GitHub usernames of the users who should have commit permissions below:

• @jimmyleocn

This is needed in order to cut releases of the plugin or component.

If you are modifying the release permission of your plugin or component, fill out the following checklist:

Release permission checklist (for submitters)

• The usernames of the users added to the "developers" section in the .yml file are the same the users use to log in to accounts.jenkins.io.
• All users added have logged in to Artifactory and Jira once.
• I have mentioned an existing team member of the plugin or component team to approve this request.

When enabling automated releases (cd: true)

Follow the documentation to ensure, your pull request is set up properly. Don't merge it yet.
In case of changes requested by the hosting team, an open PR facilitates future reviews, without derailing work across multiple PRs.

Link to the PR enabling CD in your plugin

CD checklist (for submitters)

• I have provided a link to the pull request in my plugin, which enables CD according to the documentation.

Reviewer checklist

• Check that the $pluginId Developers team has Admin permissions while granting the access.
• In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
• If security contacts are changed (this includes add/remove), ping the security officer (currently @Wadeck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it.

[alecharp]

Hi @jimmyleocn, it seems that you have modified the file extensively. Could you please make sure to only change the lines you intent to modify (developers array imo).

Could you please make sure to login Jira and Artifactory using your account from accounts.jenkins.io? Thanks.

[jimmyleocn]

Hi @jimmyleocn, it seems that you have modified the file extensively. Could you please make sure to only change the lines you intent to modify (developers array imo).

I can revert my commit and create a new one that only updates the developers field. However, I'm wondering about the paths field - do I need to add a new path to match the groupId 'org.jenkins-ci.plugins' that I've changed in the pom.xml?

Could you please make sure to login Jira and Artifactory using your account from accounts.jenkins.io? Thanks.

I can confirm that I’ve logged into both sites using my Jenkins account.

@alecharp

[MarkEWaite]

I can revert my commit and create a new one that only updates the developers field. However, I'm wondering about the paths field - do I need to add a new path to match the groupId 'org.jenkins-ci.plugins' that I've changed in the pom.xml?

I believe that changing the groupID in the pom file is not a good choice. Users don't see the group ID but users might be disrupted if a change of the groupID causes Jenkins to believe that it is a new plugin rather than an upgrade of an existing plugin.

I'm not confident on the precise details of the cases where groupID and artifactID can be changed, but I am confident that leaving them unchanged is almost always the right choice.

[jimmyleocn]

I can revert my commit and create a new one that only updates the developers field. However, I'm wondering about the paths field - do I need to add a new path to match the groupId 'org.jenkins-ci.plugins' that I've changed in the pom.xml?

I believe that changing the groupID in the pom file is not a good choice. Users don't see the group ID but users might be disrupted if a change of the groupID causes Jenkins to believe that it is a new plugin rather than an upgrade of an existing plugin.

I'm not confident on the precise details of the cases where groupID and artifactID can be changed, but I am confident that leaving them unchanged is almost always the right choice.

What I mean is, in pom.xml, the /project/parent/groupId node was originally 'org.jvnet.hudson.plugins'. It seems we'll get build errors if we don't update it to 'org.jenkins-ci.plugins' when upgrading to the newer parent version 4.75?

[alecharp]

It's true that as the plugin used a very old parent pom, it has the old groupId. I think it's fine to have the new path here.
But we would greatly appreciate if the only changes in the pull request were the develops and path entries.

[jimmyleocn]

It's true that as the plugin used a very old parent pom, it has the old groupId. I think it's fine to have the new path here. But we would greatly appreciate if the only changes in the pull request were the develops and path entries.

All done on revert and recommit. Would you like help me to check if everything is OK? Thanks!

[mawinter69]

To my knowledge a plugin is solely identified by its artifactid. The groupid doesn't matter at all.

[timja]

To my knowledge a plugin is solely identified by its artifactid. The groupid doesn't matter at all.

Yes although it breaks any bom/renovate/dependabot automatic updates

[alecharp]

This looks good. Thanks for adopting the plugin @jimmyleocn.

[jimmyleocn]

This looks good. Thanks for adopting the plugin @jimmyleocn.

Thanks for your help, and thanks to @timja for the suggestions as well!