Automatically detects plugins up for adoption

[alecharp]

The tasks to mark a plugin up for adoption is manual.
However, when the developers list is empty, no one has the permission to push a new release to Artifactory.
It means that no one (admins and security officers don't count) can push a new bug fix to users.

Out of fairness for the users, I think it would be ok to mark any plugin without any developers as up for adoption.

This is of course, up for debate.

[lemeurherve]

This seems a great addition to me!

Some small suggestions.

[jglick]

Beware that we have not yet resolved the question of how GitHub write/admin permissions should be managed—ideally in the same file as Artifactory permissions. For CD-enabled plugins ideally we would grant GH write permission to maintainers without also granting Artifactory permissions. For now, we informally treat the user list here as a record of who should be granted GH permissions for existing plugins, but it is not mechanically enforced and it takes an org admin with as ops bot to actually approve the grant.

I doubt many/any of the plugins you found would be affected, but I would recommend skipping this logic when cd.enabled is set.

CC @daniel-beck

[timja]

For CD-enabled plugins ideally we would grant GH write permission to maintainers without also granting Artifactory permissions

It's currently also a fallback not removing from RPU so if trusted.ci breaks you can still release a CD plugin without having to wait till it gets fixed.

and security team uses it for security contacts...

[jglick]

so if trusted.ci breaks you can still release a CD plugin

Huh? CD releases operate via GHA. Admittedly there are various reasons why CD might be temporarily broken and you might wish to cut an emergency release manually without filing a helpdesk ticket.

[timja]

Admittedly there are various reasons why CD might be temporarily broken and you might wish to cut an emergency release manually without filing a helpdesk ticket

exactly

Huh?

tokens aren't valid very long and require trusted.ci to be constantly updating them

[alecharp]

For the record, one of the first tasks to adopt a plugin in https://www.jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/ is to remove the topic on the repository. So I didn't expect the permissions to be a problem.

I doubt many/any of the plugins you found would be affected, but I would recommend skipping this logic when cd.enabled is set.

This is something I can add yes. However, a plugin can be release and still have no maintainers. An admin or a security member could theoretically merge pull requests from dependabot and force a release through CD. And yet, the plugin should be mark as up for adoption.

This is a flag to invite a new person willing to work on a plugin to do so.

[daniel-beck]

IMO this would be better as a one-off cleanup and then something just done on merge when removing the last maintainer from the list. I don't see a need for this to run every 30 or so minutes.

[alecharp]

I feel like, because it's easy to forget, having it automatic, we (not me but others) won't have to think about it.

[halkeye]

Why not just have have update center as reporting it as up for adoption. It already has the facilities to add labels and read the developers list and stuff, and wouldn't need an extra file to be archived/published and co summed by others.

[daniel-beck]

Why not just have have update center as reporting it as up for adoption. It already has the facilities to add labels and read the developers list and stuff, and wouldn't need an extra file to be archived/published and co summed by others.

Great idea. Will do that next weekend or before then.

[alecharp]

any solution is fine to me, as long as we have one ;)

[daniel-beck]

FTR I filed jenkins-infra/update-center2#654 and #2911