ci: publish to npm via OIDC trusted publishing instead of NPM_TOKEN - #16
Conversation
The release job on master failed: OIDC token exchange with the npm registry failed: 404 OIDC token exchange error - package not found ENONPMTOKEN No npm token specified. semantic-release v25 does attempt trusted publishing, so the fix is to remove the token fallback and satisfy the two things OIDC actually needs: - Drop the NPM_TOKEN env from both release paths. No long-lived credential. - Add registry-url to setup-node so the registry is configured for auth. - Upgrade npm before publishing: trusted publishing requires npm >= 11.5.1 and Node 22 ships npm 10.x. Also fixes a second, independent blocker. The repository had no git tags at all, and semantic-release derives the next version from tags rather than from the registry — so it would have recomputed 1.0.0 and collided with the version already on npm. Pushed a v1.0.1 baseline tag at 768d583, which is the commit the published exostate@1.0.1 records as its gitHead, so the next release computes 1.1.0 from the feat: commits that follow it. package.json version synced to 1.0.1 to match the registry; semantic-release overwrites it at release time. Note: this still requires a trusted publisher to be configured for `exostate` on npmjs.com, bound to this repository and workflow. That is a one-time step in the npm UI and cannot be done from CI.
|
Warning Review limit reached
Next review available in: 25 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🎉 This issue has been resolved in version 1.1.0. |
1 participant
Fixes the failed release on
master.What broke
Two independent blockers
1. OIDC was not fully wired. semantic-release v25 does attempt trusted publishing, so the fix is to remove the token fallback and satisfy what OIDC needs:
NPM_TOKENfrom both release paths — no long-lived credentialregistry-urltosetup-nodenpm install -g npm@latest— trusted publishing requires npm >= 11.5.1 and Node 22 ships npm 10.x2. No git tags existed. semantic-release derives the next version from git tags, not from the registry. With zero tags it would have recomputed
1.0.0and collided with what is already published.Pushed a
v1.0.1baseline tag at768d583— that is the exact commit the publishedexostate@1.0.1records as itsgitHead, so this is reconstructed from the registry rather than guessed. The next release now computes 1.1.0 from thefeat:commits that follow it.Required before merging
A trusted publisher must be configured for
exostateon npmjs.com, bound to this repository and workflow file. This is a one-time step in the npm UI and cannot be done from CI. Without it the token exchange keeps returning the 404 above.npmjs.com →
exostate→ Settings → Trusted Publisher:webcoderspeedexostateci.ymlMerging before that step is configured will simply fail the release job again — nothing is published and nothing is damaged.