Summary
cargo wdk should support passing --locked through to the underlying cargo build / cargo check invocations it spawns.
Motivation
The --locked flag is critical for reproducible builds. It ensures that Cargo.lock is respected exactly as committed, preventing any dependency resolution changes at build time. This matters for:
- CI/CD reproducibility — builds must be deterministic; without
--locked, a CI run can silently pick up a different dependency version than what was tested locally, leading to hard-to-diagnose regressions.
- Security & supply-chain integrity —
--locked guarantees that only audited, committed dependency versions are used. Without it, a compromised or yanked crate version could be silently substituted.
- Compliance with Cargo best practices — the Rust ecosystem strongly recommends
--locked for production and release builds. Driver development, where correctness is safety-critical, should be no exception.
- Parity with
cargo make workflows — existing CI pipelines (e.g., codeql.yml) already pass --locked via cargo make. As cargo wdk replaces cargo make, it must support the same flags to avoid workflow regressions.
Expected Behavior
When a user runs:
The --locked flag is forwarded to the underlying cargo build invocation, so that Cargo.lock is enforced and the build fails if the lockfile is out of date.
Current Behavior
cargo wdk does not recognize or forward --locked, so there is no way to enforce lockfile-pinned builds through the cargo wdk interface.
Proposed Solution
Forward --locked (and ideally the related --frozen and --offline flags) from cargo wdk to the inner cargo commands it invokes. This is a passthrough — cargo wdk does not need to interpret the flag itself, only ensure it reaches cargo build / cargo check.
Impact
High — Blocks adoption of cargo wdk in CI pipelines that require deterministic, lockfile-enforced builds. This is a prerequisite for fully deprecating cargo make in WDR workflows.
Summary
cargo wdkshould support passing--lockedthrough to the underlyingcargo build/cargo checkinvocations it spawns.Motivation
The
--lockedflag is critical for reproducible builds. It ensures thatCargo.lockis respected exactly as committed, preventing any dependency resolution changes at build time. This matters for:--locked, a CI run can silently pick up a different dependency version than what was tested locally, leading to hard-to-diagnose regressions.--lockedguarantees that only audited, committed dependency versions are used. Without it, a compromised or yanked crate version could be silently substituted.--lockedfor production and release builds. Driver development, where correctness is safety-critical, should be no exception.cargo makeworkflows — existing CI pipelines (e.g.,codeql.yml) already pass--lockedviacargo make. Ascargo wdkreplacescargo make, it must support the same flags to avoid workflow regressions.Expected Behavior
When a user runs:
The
--lockedflag is forwarded to the underlyingcargo buildinvocation, so thatCargo.lockis enforced and the build fails if the lockfile is out of date.Current Behavior
cargo wdkdoes not recognize or forward--locked, so there is no way to enforce lockfile-pinned builds through thecargo wdkinterface.Proposed Solution
Forward
--locked(and ideally the related--frozenand--offlineflags) fromcargo wdkto the innercargocommands it invokes. This is a passthrough —cargo wdkdoes not need to interpret the flag itself, only ensure it reachescargo build/cargo check.Impact
High — Blocks adoption of
cargo wdkin CI pipelines that require deterministic, lockfile-enforced builds. This is a prerequisite for fully deprecatingcargo makein WDR workflows.