ci: support npm trusted publishing recovery#122
Conversation
|
@greptileai review |
Greptile SummaryThis PR adds npm Trusted Publishing and a manual publication recovery path. The main changes are:
Confidence Score: 4/5The manual publication path can target the wrong package version and may still select empty token authentication.
.github/workflows/release-please.yml Important Files Changed
Reviews (1): Last reviewed commit: "ci: support npm trusted publishing recov..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if: ${{ steps.release.outputs.release_created || (github.event_name == 'workflow_dispatch' && inputs.publish) }} | ||
| uses: actions/checkout@v7 |
There was a problem hiding this comment.
On a manual recovery, checkout uses the branch selected in the workflow UI rather than the tag for the failed release. If main has advanced before recovery, pnpm publish reads its current version and files, so the workflow can publish a different package or fail while leaving the intended release unpublished.
| env: | ||
| # Trusted Publishing uses the workflow's id-token permission. NPM_TOKEN | ||
| # remains available as a fallback for token-based npm authentication. | ||
| NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} |
There was a problem hiding this comment.
When NPM_TOKEN is not configured, this still exports NODE_AUTH_TOKEN as an empty value while setup-node has configured registry authentication around that variable. If pnpm treats the resulting token configuration as explicit authentication, it attempts an unauthenticated publish instead of Trusted Publishing, reproducing the recovery failure despite id-token: write; only set this environment variable when the fallback secret exists.
Greptile SummaryThis PR adds npm Trusted Publishing support and a manual release-recovery path. The main changes are:
Confidence Score: 4/5The manual recovery path should be bound to the intended release ref before merging.
.github/workflows/release-please.yml Important Files Changed
Reviews (2): Last reviewed commit: "ci: support npm trusted publishing recov..." | Re-trigger Greptile |
|
|
||
| - name: Checkout repository | ||
| if: ${{ steps.release.outputs.release_created }} | ||
| if: ${{ steps.release.outputs.release_created || (github.event_name == 'workflow_dispatch' && inputs.publish) }} |
There was a problem hiding this comment.
A manual dispatch checks out whichever branch or tag the operator selects, while the skipped Release Please step provides no release commit to bind the run to. Selecting a feature branch or older tag with publish=true can therefore publish that ref's package contents instead of the contents of the existing GitHub release being recovered.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #122 +/- ##
=======================================
Coverage 47.81% 47.81%
=======================================
Files 50 50
Lines 5733 5733
Branches 1671 1713 +42
=======================================
Hits 2741 2741
Misses 2990 2990
Partials 2 2 🚀 New features to boost your workflow:
|
1 participant
Summary
id-token: writepermission required for npm Trusted Publishingpublishworkflow input for recovering an already-created GitHub releaseNPM_TOKENfallback, and the recovery procedureRoot cause
The v1.5.0 GitHub release was created successfully, but the publish step received an empty
NPM_TOKEN. pnpm skipped OIDC because the workflow had noid-token: writepermission and npm rejected the unauthenticated publish with404 Not Found.Validation
pnpm checkpnpm check)Required follow-up
Configure npm Trusted Publishing for
sebastian-software/offcourseand.github/workflows/release-please.yml, or add anNPM_TOKENrepository secret. Then run theReleaseworkflow manually withpublishset totrueto publish the existing v1.5.0 package.Refs #92