Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trusted Publishing: suboptimal UX with pending publishers and monorepos #16920

Open
woodruffw opened this issue Oct 18, 2024 · 0 comments
Open
Assignees
Labels
trusted-publishing UX/UI design, user experience, user interface

Comments

@woodruffw
Copy link
Member

PyPI supports pending publishers for pre-registering a trusted publisher for a nonexistent PyPI project. This breaks the "chicken and egg" cycle of having to create a project before registering a trusted publisher to it.

To support this, PyPI allows multiple pending publishers to be registers to a future PyPI project name, with "first come first serve" rules -- the first workflow to actually use the pending publisher is the one that creates the project + has the full TP assigned to it.

To make this work, PyPI has uniqueness constraints on pending publishers that are similar to normal TPs. For example, for GitHub, a pending publisher must be unique on (owner, repo, workflow, environment?) -- only one pending publisher for that tuple may be created, and attempting to create multiple fails.

That works well for most users, but it results in an edge cases for monorepos (i.e. one repo, multiple Python projects). To bootstrap a monorepo a user might want to create N pending publishers, one for each project. However, they can't currently do this send pending publishers currently have unique repo identities.

Monorepo users have a few workarounds available to them:

  1. They can go back to the "chicken and egg" approach and create the project(s) via an explicitly provisioned API token, and then register normal TPs as usual;
  2. They can create a single pending publisher for one project within the repo, perform a publish event, and then manually enroll the other projects with the now-created TP;
  3. They can do everything with manually provisioned API tokens and skip TP entirely (which we don't want to encourage)

All three of these are suboptimal from a UX perspective, and all three are semi-undocumented (in the sense that the monorepo case isn't explicitly called out as an edge case in the TP docs).

Action items:

  • Can we improve the UX here? Conceptually the monorepo case requires loosening the unique constraint, which is unsound/impossible (since we need to uniquely map back to the TP during pending -> normal conversion). But there might be a way to do this that doesn't cause uniqueness issues there; requires more thought.
  • We should explicitly call out the monorepo pending publisher case in the docs.

h/t @miketheman

@woodruffw woodruffw added UX/UI design, user experience, user interface trusted-publishing labels Oct 18, 2024
@woodruffw woodruffw self-assigned this Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
trusted-publishing UX/UI design, user experience, user interface
Projects
None yet
Development

No branches or pull requests

1 participant