ci: pin rivet-cli to v0.19.0 + version-key its cache (#242 release cadence)#464
Merged
Conversation
…lease cadence, #242) Unpinned `rivet --branch main` in the Rivet Validation job has now red-failed a release TWICE — both times on unchanged artifacts: - #229: rivet 0.15.0 promoted a status-enum check WARN→ERROR (schema drift). - v0.14.0: rivet 0.19.0's HiGHS C++ dependency filled a self-hosted runner's disk on a full rebuild (No space left on device). The rebuild was triggered because the bin cache was keyed on Cargo.lock, which a release version bump invalidates. Two fixes, both frozen-safe (CI-only; zero codegen change → frozen fixtures bit-identical by construction): 1. PIN the install to release tag v0.19.0 (validated clean on this repo's artifacts: non-xref ERROR 0, coverage exit 0). Schema/behaviour bumps become deliberate, not surprise gate-rednenings. 2. KEY the rivet-cli binary cache on the pinned version (not Cargo.lock), cache only `~/.cargo/bin/rivet`, and skip the build when that exact version is already present. A release's Cargo.lock change no longer forces the HiGHS rebuild that filled the disk. Self-healing on persistent self-hosted runners: a stale binary fails the version grep → `cargo install --force --tag v0.19.0` pins it back. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
1 participant
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
Pin the
Rivet Validationjob'srivet-cliinstall, and stop its binary cache from invalidating on every release. CI-only / frozen-safe — zero codegen change, frozen fixtures bit-identical by construction.Why
Unpinned
rivet --branch mainhas now red-failed a release twice, both on unchanged artifacts:No space left on device). The rebuild fired because the bin cache was keyed onCargo.lock, which a release version bump invalidates.Both cost diagnosis + re-run time, and the next release (the queued imm-shift-fold flip) would hit the same trap.
Fix (two parts)
~/.cargo/bin/rivetcache (notCargo.lock) and skip the build when that exact version is already present. A release'sCargo.lockchange no longer forces the HiGHS rebuild.Self-healing on persistent self-hosted runners: a stale binary fails the version grep →
cargo install --force --tag v0.19.0pins it back.The PR's own Rivet Validation run is the gate — it must stay green.
🤖 Generated with Claude Code