fix: unblock publish job on auto-incrementing release branch#67
fix: unblock publish job on auto-incrementing release branch#67alexmercerpo wants to merge 1 commit into
Conversation
The publish job's first step ran `yarn install --immutable`, which fails on a long-lived auto-incrementing release branch whose committed yarn.lock lags the bumped package.json versions (stale @enclave-vm/*@npm:2.13.0 entries that a clean install prunes). Immutable mode forbids the prune, so the job died at setup before any version-bump/lock-sync step could run. Set `install: "false"` on Setup Node + Yarn and add an explicit `yarn install --no-immutable` step. The publish job is the source of truth for versions and rewrites the lock every run, so it self-heals drift instead of deadlocking. Immutable installs still guard normal PR/push CI. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughIn ChangesRelease Workflow Dependency Install Fix
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Problem
The Publish Release workflow fails at its very first step (
Setup Node + Yarn→yarn install --immutable) onrelease/2.14.x:release/2.14.xis consistent at the package.json level (libs and apps all at2.14.0), butyarn.lockstill carries a disconnected, self-referential cluster of stale@enclave-vm/*@npm:2.13.0entries (PR #65 did not actually prune them). A clean install prunes that cluster; immutable mode forbids it, so the job dies before any version-bump / lock-sync step runs.This is structural:
release/*is a long-lived, auto-incrementing branch. Its committed lockfile legitimately lags the bumped versions, and the publish job rewrites the lock every run — so an immutable check at setup is the wrong guard there.Fix
Setup Node + Yarn→install: "false"(skip the immutable install)Install dependenciesstep →yarn install --no-immutableThe publish job is the source of truth for versions, so it now self-heals lockfile drift instead of deadlocking. The next run prunes the stale entries, computes the next patch (
2.14.1, sincev2.14.0is already published/tagged), bumps, syncs the lock, and commits a clean lockfile. Immutable installs still guard normal PR/push CI.Pairs with the already-merged post-bump
Sync lockfile to bumped versionsstep.🤖 Generated with Claude Code
Summary by CodeRabbit