VA-52: catch a stale Cargo.lock in the PR check (--locked) #56

Merged

nrupard merged 1 commit from fix/VA-52-ci-locked-build into main

2026-06-12 23:39:15 +02:00

nrupard commented

2026-06-12 23:37:02 +02:00

Owner

Summary

VA-52: build-package.yml run #189 failed on the VA-9 merge (f747915a). Root cause: that commit added windows-service to crates/vervain-agent/Cargo.toml but the committed Cargo.lock had no entry for it (433 vs 503 packages now). The release build runs cargo build --release --locked, which fails the lock-consistency check; the failure was 21s (a resolve error, not a compile failure).

Why the PR check missed it: oci-build/check.Dockerfile built without --locked, so it resolved a fresh in-container lock and passed. The in-container resolution is discarded (COPY-in build), so the stale committed lock reached main and only build-package.yml (which uses --locked) caught it - post-merge.

Already healthy on main

The build itself is fine now: the VA-10 merge regenerated Cargo.lock (a host-mounted build wrote the windows-service + webrtc entries back), and build-package run #194 is green. So this PR does not fix a current breakage - it prevents the recurrence.

Change

Add --locked to the clippy / build / test / windows-cross-check steps in oci-build/check.Dockerfile. A stale Cargo.lock now fails the PR check instead of leaking to the post-merge package build. Cargo resolves the whole-graph lock (all targets) regardless of build target, so the host-target steps also catch a missing cfg(windows) (or other target-gated) dependency.

Validation

oci-build/check.Dockerfile (now --locked throughout) passes on current main: fmt, clippy --deny warnings, build, full test suite, and the Windows cross-check.

Refs VA-52.

## Summary VA-52: `build-package.yml` run #189 failed on the VA-9 merge (`f747915a`). Root cause: that commit added `windows-service` to `crates/vervain-agent/Cargo.toml` but the committed `Cargo.lock` had no entry for it (433 vs 503 packages now). The release build runs `cargo build --release --locked`, which fails the lock-consistency check; the failure was 21s (a resolve error, not a compile failure). Why the PR check missed it: `oci-build/check.Dockerfile` built **without** `--locked`, so it resolved a fresh in-container lock and passed. The in-container resolution is discarded (COPY-in build), so the stale committed lock reached `main` and only `build-package.yml` (which uses `--locked`) caught it - post-merge. ## Already healthy on main The build itself is fine now: the VA-10 merge regenerated `Cargo.lock` (a host-mounted build wrote the windows-service + webrtc entries back), and build-package run #194 is green. So this PR does not fix a current breakage - it prevents the recurrence. ## Change Add `--locked` to the clippy / build / test / windows-cross-check steps in `oci-build/check.Dockerfile`. A stale `Cargo.lock` now fails the PR check instead of leaking to the post-merge package build. Cargo resolves the whole-graph lock (all targets) regardless of build target, so the host-target steps also catch a missing `cfg(windows)` (or other target-gated) dependency. ## Validation `oci-build/check.Dockerfile` (now `--locked` throughout) passes on current main: fmt, clippy --deny warnings, build, full test suite, and the Windows cross-check. Refs VA-52.

nrupard added 1 commit

2026-06-12 23:37:02 +02:00

fix(ci): build with --locked in the PR check to catch a stale Cargo.lock

Check / clippy + fmt + tests (pull_request) Successful in 1m57s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

280471bdaf

VA-52: `build-package.yml` failed on the VA-9 merge (run #189) because that commit added `windows-service` to `Cargo.toml` but never regenerated `Cargo.lock` (the in-container CI builds discard the lock change). The release build uses `cargo build --release --locked`, so it failed the lock-consistency check post-merge - while the PR check (`oci-build/check.Dockerfile`) built without `--locked` and silently resolved a fresh lock, so it passed.

The build itself is already healthy on main (the VA-10 merge regenerated the lock; build-package run #194 is green). This adds `--locked` to the clippy/build/test/windows steps of the PR check so a stale lock fails the PR instead of leaking to the post-merge package build. Cargo resolves the whole-graph lock regardless of build target, so the host-target steps also catch a missing `cfg(windows)` dependency.

Verified: `oci-build/check.Dockerfile` (now `--locked` throughout) passes on current main.

#VA-52

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>