Enabling CD and adding security contacts for gcp-java-sdk-plugin

[aneveux]

Link to GitHub repository

https://github.com/jenkinsci/gcp-java-sdk-plugin

When modifying release permission

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

Release permission checklist (for submitters)

Preview Give feedback

1. 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.
2. All users added have logged in to Artifactory and Jira once.
3. 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 should be already enabled in my plugin, I followed the documentation before being hosted on jenkinsci not knowing I should have done that afterwards.

CD checklist (for submitters)

Preview Give feedback

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

Reviewer checklist

Preview Give feedback

1. Check that the $pluginId Developers team has Admin permissions while granting the access.
2. In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
3. 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.

[timja]

I assume you have more paths than that, and each one of those needs cd.enabled set?

based on looking at https://github.com/jenkinsci/gcp-java-sdk-plugin/tree/master

the other 2 modules

[aneveux]

Oh you are right, I totally missed that.

Thanks a lot for the good catch ❤️

[aneveux]

Pinging @Wadeck here as I added the Security Contacts.

[Wadeck]

👍 Thanks for the correct ping :)

[timja]

Oh you are right, I totally missed that.

Thanks a lot for the good catch ❤️

Each plugin should have it's own file if you want maintainers to show up on the plugin site.
The wildcard path is generally for non plugins that have quite a few modules, e.g. bom which adds new ones every few months and maintainers don't need to show up

[aneveux]

@timja I used a wildcard path simiarly to what is done in the aws-sdk plugin.

This plugin is just an API plugin that does not contain any source code but simply serves GCP dependencies to other plugins requiring them, there are no "per-plugin maintainers" per se, as each plugin is just a pom.xml with specific dependencies.

Is that OK to keep it like this, consistent with the aws-sdk or do you prefer that I create one file per plugin?

[timja]

@timja I used a wildcard path simiarly to what is done in the aws-sdk plugin.

This plugin is just an API plugin that does not contain any source code but simply serves GCP dependencies to other plugins requiring them, there are no "per-plugin maintainers" per se, as each plugin is just a pom.xml with specific dependencies.

Is that OK to keep it like this, consistent with the aws-sdk or do you prefer that I create one file per plugin?

it's fine, but if someone views one of them on plugin site maintainers will be empty, you can always change it later if you want.

[timja]

@timja I used a wildcard path simiarly to what is done in the aws-sdk plugin.

This plugin is just an API plugin that does not contain any source code but simply serves GCP dependencies to other plugins requiring them, there are no "per-plugin maintainers" per se, as each plugin is just a pom.xml with specific dependencies.

Is that OK to keep it like this, consistent with the aws-sdk or do you prefer that I create one file per plugin?

noting #2911