Skip to content

fix(release): regenerate the capi lockfile and guard both against version drift - #451

Merged
paudley merged 1 commit into
mainfrom
fix/capi-lockfile-release-incident
Sep 4, 2026
Merged

fix(release): regenerate the capi lockfile and guard both against version drift#451
paudley merged 1 commit into
mainfrom
fix/capi-lockfile-release-incident

Conversation

@paudley

@paudley paudley commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator

Release incident, recorded per docs/GTS-V1-RC1-CHECKLIST.md:425.

What happened

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, which still named gmeow-gts 0.9.11.

Why nothing caught it

  • cargo metadata does not need --locked, so the manifest check passed.
  • CI does not build capi with --locked.
  • check-versions.sh only 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

Tag Outcome
rust-v1.0.0-rc.1 published to crates.io successfully
capi-v1.0.0-rc.1 published nothing — both workflows failed at the build step, before any registry upload or release artifact

No 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 both Cargo.lock files already name the release version — so a bump that forgets one fails in CI, not at publish time.

Verified falsifiable:

$ # revert either lockfile to 0.9.11
$ bash scripts/check-versions.sh
ERROR: rust/capi/Cargo.lock does not name gmeow-gts-capi 1.0.0-rc.1;
       regenerate it (cargo update -p gmeow-gts-capi).
exit 1

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

  • Chores
    • Improved release artifact handling by excluding release-candidate bundles from repository content.
    • Strengthened release checks to verify that Rust package versions remain consistent across supported components.
    • Version mismatches are now reported as errors during validation.

@paudley
paudley requested a review from ErinAudley as a code owner September 4, 2026 18:00
@coderabbitai

coderabbitai Bot commented Sep 4, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: c38b889a-7e00-4d94-a2fb-8c183d430362

📥 Commits

Reviewing files that changed from the base of the PR and between aeca558 and 9963eb6.

⛔ Files ignored due to path filters (1)
  • rust/capi/Cargo.lock is excluded by !**/*.lock
📒 Files selected for processing (2)
  • .gitignore
  • scripts/check-versions.sh

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.


📝 Walkthrough

Walkthrough

The changes ignore versioned release-candidate bundles and extend version validation to the main Rust and C ABI Cargo lockfiles.

Changes

Artifact filtering

Layer / File(s) Summary
Ignore release artifacts
.gitignore
Adds dist/v*/ to exclude release-candidate artifact bundles.

Lockfile version validation

Layer / File(s) Summary
Validate Rust lockfile versions
scripts/check-versions.sh
Checks the main and C ABI Cargo lockfiles against rust_v. Version mismatches emit errors and set the global error status.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 9963e

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)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the main changes: regenerating the capi lockfile and adding protection against version drift. It is concise and specific.
Description check ✅ Passed The description is detailed and on-topic. It explains the release incident, impact, root cause, fix, affected Rust components, and a falsifiable validation result. It does not use the template's expli…
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/capi-lockfile-release-incident

Comment @coderabbitai help to get the list of available commands.

…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.
@paudley
paudley force-pushed the fix/capi-lockfile-release-incident branch from d54f632 to 9963eb6 Compare September 4, 2026 18:11
@paudley
paudley merged commit ab81810 into main Sep 4, 2026
31 checks passed
@paudley
paudley deleted the fix/capi-lockfile-release-incident branch September 4, 2026 18:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant