ci: publish through GitHub Actions trusted publishing - #1
Merged
Conversation
Releases now happen by merging the Changesets version pull request. One workflow maintains that pull request and publishes once no changesets remain; nothing else publishes. Authentication uses a short-lived GitHub Actions OIDC credential. pnpm performs the npm token exchange itself, and `changeset publish` resolves the publishing tool from `packageManager`, so it is already on that path. pnpm is also the only option that rewrites the `workspace:` ranges in layout and three into registry-safe semver, so it stays the publish tool. pnpm degrades a failed exchange to a `Skipped OIDC` warning and publishes anyway, so a green run is not evidence of a trusted release. Two guards cover that: a wrapper fails the release when the warning appears on the publish output, and a post-publish check reads the registry packument and requires trusted-publisher plus provenance evidence on every version. The check reads the packument directly because `npm view` renders `_npmUser` as a display string and drops the nested `trustedPublisher` object. The workflow keeps the filename publish.yml because all four packages' trusted publishers already name it, and npm matches that against the token's job_workflow_ref claim. Renaming it now breaks releases silently, so the file and the docs both say not to. Also delete the stale root RELEASING.md, which still described the pre-launch gates and the manual sequence that docs/RELEASING.md replaced. No package source, public API, or consumer-visible behavior changes.
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
Group 1 confirmed against npm: all four packages already had a trusted publisher naming publish.yml, which is why the workflow was renamed to match rather than editing four npm forms. Group 4 rewritten — the OIDC exchange cannot be rehearsed locally, since getIdToken() returns undefined without GITHUB_ACTIONS, so the tasks now cover what can actually be checked before the first publish.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Releases now happen by merging the Changesets version pull request. One workflow maintains that PR and publishes once no changesets remain; nothing else publishes.
What changed
release-pr.ymlrenamed topublish.ymland given thepublishinput plusid-token: write. The old manual-dispatchpublish.ymlis retired.pnpm checkandpnpm release:candidatenow gate the release path, not just PRs.Skipped OIDCfallback (see below).RELEASING.mddeleted;docs/RELEASING.mdrewritten.Why the filename is
publish.ymlAll four packages' npm trusted publishers already name
publish.yml, and npm matches that against the OIDC token'sjob_workflow_refclaim. Renaming the file breaks releases silently, so the workflow header and the docs both say not to.Why two guards
pnpm publishperforms the npm OIDC exchange itself, but when it fails it only warns —Skipped OIDC— and publishes with whatever credential is reachable. A green run is therefore not evidence of a trusted release:release:publish:ciwraps the publish, fails on the warning, and forwards stdout byte-for-byte (changesets/action parses it forpublished/publishedPackages).verify-release-trust.mjsreads the registry packument and requires_npmUser.trustedPublisher+dist.attestations.provenance, one coordinated version, and no survivingworkspace:ranges.The verifier reads the packument directly rather than via
npm view, which renders_npmUseras a display string and drops the nestedtrustedPublisherobject.Notes
0.1.xcarries no trust evidence, so the first automated release is a strict trust upgrade and cannot trip pnpm's install-side downgrade check.Spec:
openspec/changes/automate-trusted-publishing/