You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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:
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.
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.
Whatever metadata accommodations occur here also need to work with any future platforms supported by Trusted Publishing (e.g. Google, GitLab, etc.).
We would very much love to have it. We are working on implementing Trusted Publishing for Apache Airflow - and more broadly for all Python Apache Software Foundation projects - and we have 90+ projects to configure for Trusted Publishing :).
While doable manually - it takes hours to do using Web interface. It would be great to be able to manage it via API.
From https://github.com/pypi/pypi-oidc-private-beta-community/issues/34:
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:
The text was updated successfully, but these errors were encountered: