Summary
release-please bumps the crate versions in every Cargo.toml but never updates Cargo.lock, so the committed lockfile drifts further from the manifests with each release. It is harmless today because nothing in the build/release pipeline uses --locked, but it turns into a hard build failure the moment anything does.
Current state (main @ ad7c2b2)
.release-please-manifest.json and every crate Cargo.toml: 0.5.1Cargo.lock workspace entries: 0.5.0
The pending 0.6.0 release (#182) widens the gap to 0.6.0 in the manifests vs 0.5.0 in the lock.
Why it is harmless right now
Every cargo build in CI and the release pipeline runs unlocked, so cargo regenerates the lock in place and the build succeeds:
pr-checks.yml: cargo test --workspace, cargo build --release --workspacerelease.yml binaries job: cargo build --release --target <t> -p ...Dockerfile (release image) and Dockerfile.bins: cargo build --release ...
The only --locked in the repo is cargo install --locked cargo-audit, which installs the audit tool and has nothing to do with the workspace lock.
Why it is worth fixing
It flips from cosmetic to a hard failure (exit 101) the instant any build adds --locked (a common reproducible-build hardening step), or on a cargo install --locked / downstream vendor step. Reproduced against the current main state in a throwaway worktree:
$ cargo metadata --locked
error: cannot update the lock file ... because --locked was passed to prevent this
$ echo $?
101
Unlocked, the same command exits 0 and rewrites the lock on disk, which is why the drift never gets committed back.
Cause
release-please-config.json uses release-type: "simple" with an extra-files list that covers the five Cargo.toml files but not Cargo.lock, so the lock is never part of the version bump.
Direction (not yet verified against this repo's config)
Either switch the package to release-type rust (its strategy maintains the workspace lockfile), or keep simple and add a post-generation step that regenerates the lock (cargo update -p <crates> or equivalent) and commits it in the release PR. Both need confirming against our setup before wiring in.
Summary
release-please bumps the crate versions in every
Cargo.tomlbut never updatesCargo.lock, so the committed lockfile drifts further from the manifests with each release. It is harmless today because nothing in the build/release pipeline uses--locked, but it turns into a hard build failure the moment anything does.Current state (main @ ad7c2b2)
.release-please-manifest.jsonand every crateCargo.toml:0.5.1Cargo.lockworkspace entries:0.5.0The pending 0.6.0 release (#182) widens the gap to
0.6.0in the manifests vs0.5.0in the lock.Why it is harmless right now
Every cargo build in CI and the release pipeline runs unlocked, so cargo regenerates the lock in place and the build succeeds:
pr-checks.yml:cargo test --workspace,cargo build --release --workspacerelease.ymlbinaries job:cargo build --release --target <t> -p ...Dockerfile(release image) andDockerfile.bins:cargo build --release ...The only
--lockedin the repo iscargo install --locked cargo-audit, which installs the audit tool and has nothing to do with the workspace lock.Why it is worth fixing
It flips from cosmetic to a hard failure (exit 101) the instant any build adds
--locked(a common reproducible-build hardening step), or on acargo install --locked/ downstream vendor step. Reproduced against the current main state in a throwaway worktree:Unlocked, the same command exits 0 and rewrites the lock on disk, which is why the drift never gets committed back.
Cause
release-please-config.jsonusesrelease-type: "simple"with anextra-fileslist that covers the fiveCargo.tomlfiles but notCargo.lock, so the lock is never part of the version bump.Direction (not yet verified against this repo's config)
Either switch the package to release-type
rust(its strategy maintains the workspace lockfile), or keepsimpleand add a post-generation step that regenerates the lock (cargo update -p <crates>or equivalent) and commits it in the release PR. Both need confirming against our setup before wiring in.