fix(ci): publish workspace packages on the beta dist-tag for prereleases - #2929
fix(ci): publish workspace packages on the beta dist-tag for prereleases#2929keesverruijt wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe release workflow now selects ChangesRelease publishing
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
The eight workspace publish steps ran a bare `npm publish`, which moves the `latest` dist-tag even when the version is a prerelease. A beta tag that also bumped a workspace package would therefore ship that package as a normal release, and every consumer on a caret range would pick it up on the next install. Derive the channel once as a job-level NPM_DIST_TAG and pass it to all nine publishes. This also replaces the inline beta branch in the signalk-server step, so one expression now governs the whole job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2ef90ad to
d670716
Compare
tkurki
left a comment
tkurki
left a comment
There was a problem hiding this comment.
The release workflow publishes submodules on demand: if the module is not yet in npm with the stated version it gets published, using the version in its package.json. These are bumped manually currently.
Using server’s tag as the single governing factor we could easily end up in a situation where a module is in beta channel but its version is a regular version.
I think this should include a preflight check that verifies early that all modules that will get published carry beta versions if server is going to be beta.
2 participants
The eight workspace publish steps ran a bare
npm publish. npm moves thelatestdist-tag on every publish unless--tagsays otherwise, and it does so even when the version string is a prerelease — so a beta tag that also bumped a workspace package would publish that package as a normal release. Consumers on a caret range would pick it up on their next install, with no way to opt out and no way to undo it (versions cannot be unpublished after 72 hours, though dist-tags can be moved).Only the final
signalk-serverpublish handled this, via an inlineifon the tag name. That inconsistency within a single job is what made the gap easy to miss.The channel is now derived once as a job-level
NPM_DIST_TAGand passed to all nine publishes, replacing the inline branch so one expression governs the job.--tag latestis npm's own default, so non-beta releases are unchanged.This matters for the next prerelease specifically:
@signalk/server-apihas unreleased breaking changes on master (feat(radar-api)!: lean RadarInfo discovery type + RadarsResponse envelope,feat(radar-api)!: drop spokeDataUrl/streamUrl from RadarInfo). Publishing those requires a version bump, which under the current workflow would put them onlatestfrom a beta tag.Follows the same
contains(github.ref, 'beta')convention as the Docker tag gating andreleasing.md. Independent of #2928, which covers the fly.io deploy.🤖 Generated with Claude Code
Summary
This PR updates the CI publish workflow to use the
betanpm dist-tag for beta prereleases across all workspace packages, includingsignalk-server.The workflow defines
NPM_DIST_TAGonce at the job level and passes it to all ninenpm publishsteps. Non-beta releases use npm’s defaultlatesttag.