Allow configuring of trusted publisher through an API (or other bulk mechanism)

[jaraco]

From https://github.com/pypi/pypi-oidc-private-beta-community/issues/34:

I feel like the long-term API tokens should allow setting up Trusted Publishing via API. Would it be possible to expose a corresponding endpoint? This can be useful for mass-maintained sets of projects that follow the same structure, like the ones relying on https://github.com/jaraco/skeleton or similar. Such an API could enable setting up new projects from templates and complement things like GitHub repository templates or cookiecutter templates. For projects migrating from the project-scoped API tokens, it might be useful to have a self-destruct API endpoint, that would expire the current token which could be used for such migration automation. Is it hard to implement such an interface?

What's the problem this feature will solve?

Allows maintainers with dozens or hundreds of projects to readily enroll with trusted publishing (and apply the requisite change upstream) without the toil of clicking through pages of web pages.

Describe the solution you'd like An addition to the REST API that lets users configure trusted publishing would readily allow automation of this process.

Alternatives for consideration:

• have trusted publishing enabled by default (maybe based on package metadata)
• allow user to bulk-configure projects, by supplying a list of projects or selecting checkboxes of all projects

[jaraco]

I thought of another alternative:

• for those rare cases where an individual wishes to bulk update projects, allow them to supply a SQL query or CSV that the administrators will run/import.

(it might just be me)

[woodruffw]

Just to tie things together: #13409 contains some more context on design blockers for an API here 🙂

have trusted publishing enabled by default (maybe based on package metadata)

I had this same idea, and I think it'd be very cool to be able to do this! There are a few risks/design wrinkles that need to be smoothed out:

1. Users who create projects from templates may end up accidentally configuring a trusted publisher for the source template, rather than the new repository they intend to use.
2. The current project metadata doesn't include everything that the trusted publisher requires. In particular, it doesn't include the GitHub Actions workflow or (optional) environment name; these would need to be shoehorned into the metadata somewhere, I think.
3. Whatever metadata accommodations occur here also need to work with any future platforms supported by Trusted Publishing (e.g. Google, GitLab, etc.).