fix(release): warm cargo cache and roll back a failed release #155
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/VA-144-warm-cargo-cache-and-rollback"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
just create-releasedies on a cold cargo cache. The version bump forces the resolver to run, and inside the dev container cargo resolves against the named volumedev-vervain-agent-cargo-registry(compose.yml:13-15), which is created EMPTY on a fresh clone, a new machine, or after a volume prune.--offlinethen has no index to read, so the update fails on whatever crate the resolver reached first ("no matching package namedanyhowfound"). This repo diverges from the sharedcommon.justrecipe, which runs the same command on the HOST against a~/.cargothat is warm by construction; the container never inherited that guarantee.Warm the volume with
cargo fetch --lockedBEFORE the version rewrite. The ordering is the whole point:--lockedrefuses as soon as the manifest and the lock disagree, so a fetch placed after the bump (the earlier attempt on this issue) aborts with "cannot update the lock file ... because --locked was passed". Fetching while the lock is still authoritative downloads exactly what is pinned, cannot alter the release commit's contents, and is a no-op once the volume is warm.--offlinestays on thecargo update --workspacestep: it is a deliberate guard that keeps unrelated dependency movement out of the release commit.Second defect fixed here: nothing between the branch creation and the commit was guarded, so any failure in that window left the version bump sitting uncommitted in the working tree on an empty
release/<tag>branch. That is how a stale version bump survived on main for a week after an aborted run, and it also blocks the next release via the dirty-tree guard with no hint of where the modification came from. Every step in that window now runs through| complete(ortryfor the nushell-internal bump) and checks its exit code; on failure the recipe prints the captured stderr, restores Cargo.toml and Cargo.lock in both the index and the worktree, returns to main, deletes the empty release branch, and exits 1. No force flags: plaingit restoreandgit branch --delete, because a delete that refuses is the signal to stop rather than something to override.Verified against removed cargo volumes (
docker compose --file compose.yml down --volumes) in a scratch clone: the old ordering reproduces theanyhowfailure, a fetch after the bump reproduces the--lockedfailure, and the new ordering runs fetch, bump, offline update and commit clean. Rollback verified twice, once with a failing update step and once with a rejecting pre-commit hook:git status --porcelainempty, HEAD back on main, norelease/*branch left. The release commit still stages only Cargo.toml and Cargo.lock, with Cargo.toml differing in the single version string and the VA-92 profile comment block intact.#VA-144
`just create-release` dies on a cold cargo cache. The version bump forces the resolver to run, and inside the dev container cargo resolves against the named volume `dev-vervain-agent-cargo-registry` (compose.yml:13-15), which is created EMPTY on a fresh clone, a new machine, or after a volume prune. `--offline` then has no index to read, so the update fails on whatever crate the resolver reached first ("no matching package named `anyhow` found"). This repo diverges from the shared `common.just` recipe, which runs the same command on the HOST against a `~/.cargo` that is warm by construction; the container never inherited that guarantee. Warm the volume with `cargo fetch --locked` BEFORE the version rewrite. The ordering is the whole point: `--locked` refuses as soon as the manifest and the lock disagree, so a fetch placed after the bump (the earlier attempt on this issue) aborts with "cannot update the lock file ... because --locked was passed". Fetching while the lock is still authoritative downloads exactly what is pinned, cannot alter the release commit's contents, and is a no-op once the volume is warm. `--offline` stays on the `cargo update --workspace` step: it is a deliberate guard that keeps unrelated dependency movement out of the release commit. Second defect fixed here: nothing between the branch creation and the commit was guarded, so any failure in that window left the version bump sitting uncommitted in the working tree on an empty `release/<tag>` branch. That is how a stale version bump survived on main for a week after an aborted run, and it also blocks the next release via the dirty-tree guard with no hint of where the modification came from. Every step in that window now runs through `| complete` (or `try` for the nushell-internal bump) and checks its exit code; on failure the recipe prints the captured stderr, restores Cargo.toml and Cargo.lock in both the index and the worktree, returns to main, deletes the empty release branch, and exits 1. No force flags: plain `git restore` and `git branch --delete`, because a delete that refuses is the signal to stop rather than something to override. Verified against removed cargo volumes (`docker compose --file compose.yml down --volumes`) in a scratch clone: the old ordering reproduces the `anyhow` failure, a fetch after the bump reproduces the `--locked` failure, and the new ordering runs fetch, bump, offline update and commit clean. Rollback verified twice, once with a failing update step and once with a rejecting pre-commit hook: `git status --porcelain` empty, HEAD back on main, no `release/*` branch left. The release commit still stages only Cargo.toml and Cargo.lock, with Cargo.toml differing in the single version string and the VA-92 profile comment block intact. #VA-144