ci(release): setup Node 24 + npm 11 for trusted publishing (OIDC)#12
Conversation
npm trusted publishing requires npm CLI ≥ 11.5.1 + Node ≥ 22.14 (https://docs.npmjs.com/trusted-publishers). The release job used only oven-sh/setup-bun, leaving the runner's default npm 10.x in PATH, so `changeset publish` → `npm publish` couldn't detect the OIDC environment and fell back to token auth → ENEEDAUTH (0.2.0 publish failed). Add actions/setup-node (Node 24 ships npm 11.x) before the changesets step. npm then auto-detects OIDC and authenticates via the trusted- publisher binding — no NPM_TOKEN, provenance auto-generated. Matches the npm docs trusted-publishers example. Pinned by SHA for dependabot.
|
|
Warning Review limit reached
Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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 Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe release workflow now includes a step to set up Node.js 24 and npm registry configuration via actions/setup-node@v4, added before the trusted publishing step, with accompanying explanatory comments. ChangesRelease Workflow Update
Estimated code review effort: 1 (Trivial) | ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
37-37: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUpdate
setup-nodeto v6. The currentactions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020pin is v4.4.0 and still runs on the deprecated Node 20 runtime, so this step will keep emitting deprecation warnings.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml at line 37, Update the release workflow’s setup-node action to the v6 release so it no longer runs on the deprecated Node 20 runtime and emits warnings. In the workflow step using actions/setup-node, replace the current pinned v4 SHA with the v6 equivalent and keep the rest of the job configuration unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/release.yml:
- Line 37: Update the release workflow’s setup-node action to the v6 release so
it no longer runs on the deprecated Node 20 runtime and emits warnings. In the
workflow step using actions/setup-node, replace the current pinned v4 SHA with
the v6 equivalent and keep the rest of the job configuration unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2e7bea55-e69a-42f2-b17f-83c535791525
📒 Files selected for processing (1)
.github/workflows/release.yml
The compressed + encrypted end-to-end tests waited only `setTimeout 0` after `setState` before reading `memory.getItem(name)`. Both backends are async (CompressionStream / crypto.subtle) and the subscribe-write settles on a macrotask, so on CI the write hadn't landed yet → `memory.getItem` returned null → `expect(...).toContain` threw "Received value must be an array type". PR #7 passed by timing luck; PR #12's CI hit the race. Replace the single `setTimeout 0` with a bounded macrotask poll until the write lands in memory. Deterministic across runner speeds.
1 participant
Summary
The 0.2.0 publish failed with
ENEEDAUTH— npm trusted publishing (OIDC) didn't engage. Root cause:release.ymlused onlyoven-sh/setup-bun, leaving the runner's default npm 10.x in PATH. npm trusted publishing requires npm CLI ≥ 11.5.1 + Node ≥ 22.14 (npm docs); with npm 10.x,changeset publish→npm publishcan't detect the OIDC environment and falls back to token auth (no token → ENEEDAUTH).Fix: add
actions/setup-node(Node 24 ships npm 11.x) before thechangesets/actionstep. npm then auto-detects OIDC and authenticates via the trusted-publisher binding (verified correct on npmjs.com:stainless-code/persist+release.yml+releaseenv). NoNPM_TOKEN; provenance auto-generated. Matches the npm docs trusted-publishers example. Pinned by SHA for dependabot.Fact-checked against official docs:
--provenance/NPM_CONFIG_PROVENANCEneeded).oidcAuthinput — trusted publishing is an npm-CLI feature, not an action feature.Test plan
bun run format:checkgreen on.github/workflows/release.ymlrelease.ymlruns →npm publish 0.2.0succeeds with provenanceSummary by CodeRabbit