ci(rust): pass --locked to cargo in Rust CI workflows - #4005
Conversation
Cargo silently re-resolves when a Cargo.toml changes without its lockfile being regenerated. Passing --locked makes CI fail loudly instead. The cosmwasm and fuel lockfiles were already stale (both still pinned pythnet-sdk 2.3.1 against a manifest that now declares 3.0.0), so they are regenerated here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Greenlight — 🚫 Blocked — see reasons below ( Blocking reasons:
|
1 similar comment
|
Greenlight — 🚫 Blocked — see reasons below ( Blocking reasons:
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
🔍 Non-regenerated lockfiles must be in sync or --locked breaks CI
Adding --locked means every workspace whose lockfile is stale relative to its Cargo.toml will now fail CI loudly. This PR only regenerated target_chains/cosmwasm/Cargo.lock and target_chains/fuel/contracts/Cargo.lock (both bumped pythnet-sdk to 3.0.0). The remaining affected jobs — fortuna, quorum, pythnet-sdk, hermes-client-rust, starknet-tools, pyth-lazer-pusher (root Cargo.lock), hermes-server, remote-executor, message-buffer, solana, stylus — rely on their existing committed lockfiles already being in sync. The author states they ran each gate command locally, but this could not be independently verified in this review environment (cargo not installed). Reviewer should confirm CI passes green for all these jobs, since a single stale lockfile in any of these workspaces would now fail the build.
Was this helpful? React with 👍 or 👎 to provide feedback.
What
Adds
--lockedto the cargo invocations in the Rust CI workflows, and regenerates the two lockfiles that turned out to be stale.Cargo respects an existing
Cargo.lockby default, so this is not a fix for an active problem — but nothing today stops a PR from bumping aCargo.tomlwithout regenerating its lockfile. CI silently re-resolves and goes green. With--lockedit fails loudly instead, which also means the dependency set CI verifies is exactly the one committed to the repo.Lockfile fixes
Two workspaces were already out of sync — both still pinned
pythnet-sdk 2.3.1against a manifest that now declares3.0.0, which also dragsborshfrom0.10.3to1.8.0:target_chains/cosmwasm/Cargo.locktarget_chains/fuel/contracts/Cargo.lockThese are regenerated here (the
cosmwasmlock also moves from lockfile format v3 to v4, which cargo writes by default from 1.78 onward; the repo pins 1.89). Since CI was already re-resolving these two on every run, the regenerated locks record what CI has effectively been building all along.SBF caveats
cargo build-sbfandcargo test-sbfare clap-based wrappers, not passthroughs — they reject unrecognized flags rather than forwarding them:cargo build-sbftakes cargo args after--, so the three Solana program builds use... -- --locked. Verified against the pinned toolchain (Solana v3.1.10): the flag reaches the underlyingcargo build.cargo test-sbfhas no equivalent. It rejects--lockedoutright, and anything after--is re-appended aftercargo test's own--, so it lands on the test binary instead of cargo.ci-remote-executor.yml'scargo test-sbfis therefore left alone, with an inline comment recording why. (ci-solana-contract.yml'scargo-test-sbfhas the same limitation.)Left out
cargo fmtdoes not accept--locked, so all format-check steps are untouched.Three other cargo invocations in
.github/workflows/are outside this change and may be worth a follow-up:publish-*.ymlworkflows'cargo publish—--lockedis accepted there, but these are release workflows, so failing a publish on a stale lockfile is a different risk trade-off than failing CIci-near-contract.yml'scargo near build reproducible-wasm— a docker-based reproducible build with its own arg handlingDockerfiles are tracked separately.
Verification
Every changed command was run locally against the repo's pinned toolchains: clippy/build/test for cosmwasm (43 tests pass), a full build plus test compile for fuel, and clippy or the equivalent gate command for fortuna, quorum, pythnet-sdk, hermes-server, hermes-client-rust, pyth-lazer-pusher, message-buffer, remote-executor, solana, starknet-tools, and stylus-nostd. All three
cargo build-sbf ... -- --lockedlines were run for real, including the--features pro-compatiblematrix variant.