fix(release): regenerate the capi lockfile and guard both against version drift - #451
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughThe changes ignore versioned release-candidate bundles and extend version validation to the main Rust and C ABI Cargo lockfiles. ChangesArtifact filtering
Lockfile version validation
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This updates release-artifact ignore rules and adds lockfile version checks without an identified remaining merge risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
…sion drift RELEASE INCIDENT, recorded per docs/GTS-V1-RC1-CHECKLIST.md:425. capi-v1.0.0-rc.1 was pushed and both its publish workflows failed: error: cannot update the lock file .../rust/capi/Cargo.lock because --locked was passed to prevent this The version bump updated rust/capi/Cargo.toml but not rust/capi/Cargo.lock, so the lockfile still named gmeow-gts 0.9.11. Nothing caught it: `cargo metadata` does not need --locked, CI does not build capi with --locked, and check-versions.sh only ever compared MANIFEST versions. The release workflows are the first thing to build with --locked, which means the failure surfaces only after the tag is pushed. The core lockfile was regenerated during the bump; the capi one is the easy one to miss, being a second standalone lockfile that nothing else touches. Same blind spot that made dependabot leave it stale until #434. Impact: rust-v1.0.0-rc.1 published to crates.io successfully. capi-v1.0.0-rc.1 published nothing -- both release-cargo-capi and release-capi failed at the build step, before any registry or release artifact was created. No bad artifact was published, so the tag can be recreated at the corrected commit rather than burning a version. The guard now checks that BOTH Cargo.lock files already name the release version, so a bump that forgets one fails in CI instead of at publish time. Verified falsifiable: reverting either lockfile to 0.9.11 is rejected with the regenerate command. The first attempt at this check silently passed the negative test -- an unfalsifiable guard is worse than none, which this repository has already learned once this cycle.
d54f632 to
9963eb6
Compare
Release incident, recorded per
docs/GTS-V1-RC1-CHECKLIST.md:425.What happened
capi-v1.0.0-rc.1was pushed and both its publish workflows failed:The version bump updated
rust/capi/Cargo.tomlbut notrust/capi/Cargo.lock, which still namedgmeow-gts 0.9.11.Why nothing caught it
cargo metadatadoes not need--locked, so the manifest check passed.--locked.check-versions.shonly ever compared manifest versions.The release workflows are the first thing to build with
--locked— so the failure surfaces only after the tag is pushed. The core lockfile was regenerated during the bump; the capi one is the easy one to miss, being a second standalone lockfile. Same blind spot that left it stale for dependabot until #434.Impact
rust-v1.0.0-rc.1capi-v1.0.0-rc.1No bad artifact reached a registry, so the tag can be recreated at the corrected commit rather than burning a version.
The fix
Regenerates
rust/capi/Cargo.lock, and teaches the guard to check that bothCargo.lockfiles already name the release version — so a bump that forgets one fails in CI, not at publish time.Verified falsifiable:
Worth noting: my first attempt at this check silently passed the negative test — the awk quoting was mangled and it could never fire. An unfalsifiable guard is worse than none, which this repo has already learned once this cycle (#437).
Summary by CodeRabbit