ci: exercise the release npmrc path on pull requests - #23
Merged
Merged
Conversation
Ghadi8
approved these changes
Sep 21, 2026
|
🎉 This PR is included in version 0.3.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
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.
What this changes
Passes
registry-urlto thesetup-nodestep inci.yml, so every pull request writes the same.npmrcthe release job writes.Why
release.ymlis reached only by a push tomainor a manual dispatch, so no pull request runs it. That matters whenever a change edits both workflows, which every Dependabot action bump does: #15, #19 and #20 each bump an action inci.ymland inrelease.yml, and only the first half is under test when the PR goes green.Comparing the two files, the release job's
checkoutandcachesteps take the same inputs as CI's, andpersist-credentials: trueis the default anyway, so those run identically on every pull request. One input is not covered:setup-nodein the release job also receivesregistry-url, which is what makes the action write an.npmrcpointing at the npm registry and readingNODE_AUTH_TOKEN. That file is whatnpm publishauthenticates with, and no pull request has ever executed that path.Passing the same input in CI runs that code and publishes nothing, since nothing in CI calls
npm publish. Asetup-nodebump that changed how the file is written now fails on the pull request rather than on a release.The alternative is to keep verifying that path by reading release notes, which is what was done for the open bumps: the only relevant breaking change across those majors is v5 starting to cache automatically when
package.jsondeclarespackageManager, which this repository does not, so it neither activates nor collides with the existing bun cache step. That reading is worth less than a run.How the new behaviour is pinned
frame_tx_wire_tests.rsmaxCost, or thegasUseddecomposition)This PR's own CI run is the check: it exercises the step being added.
Load-bearing rules
Checks
bun run testbun run typecheckbun run build && bunx @arethetypeswrong/cli --pack .(required ifexports,files,typesVersionsortsup.config.tschanged; otherwise N/A)bun run test:live(optional, hits the public endpoint, not a gate)actionlintis clean on the edited file. The test and type checks were run on this branch and are unaffected, since the change is a workflow input.Release impact
docs,chore,test,ci,refactor,style,perf,build)fix)feat)feat!or aBREAKING CHANGE:footer)AI assistance
Related issues
N/A