Docker: copy vendor/ and pin rustc 1.95.0 - #272
Conversation
Two bugs, both pre-existing, the second hidden behind the first.
1. vendor/ was never copied
The root manifest has `[patch.crates-io] chacha20 = { path = "vendor/chacha20" }`,
and both Dockerfiles do a selective COPY -- Cargo.toml, crates/, src/,
examples/, benches/ -- that never included vendor/. Cargo resolves patch entries
while LOADING THE MANIFEST, before features and before target selection, so this
is not a link-time miss; the build dies at parse:
error: failed to load source for dependency `chacha20`
Caused by: Unable to update /app/vendor/chacha20
Caused by: failed to read `/app/vendor/chacha20/Cargo.toml`
vendor/chacha20 is tracked (18 files) and not gitignored, and .dockerignore does
not exclude vendor/ -- the directory simply was never listed. The patch arrived
in 2539cad without the Dockerfiles being updated alongside it. Same failure
class as the examples/benches note already in the file, which exists because
this happened once before.
2. The image pinned rustc 1.94.0 for a crate that requires 1.95
Cargo.toml says `rust-version = "1.95"` and rust-toolchain.toml says
channel = "1.95.0", but the Dockerfiles installed 1.94.0 and asserted it. This
would have been the very next failure after fixing (1) and was invisible until
then. rust-toolchain.toml is deliberately not copied into the image -- rustup
would fetch a second toolchain at build time -- so the Dockerfile pin is the only
thing keeping the image in step with the repo, and there is now a comment saying
so and telling the next person to bump it when the toolchain moves.
Verified by reproducing the Docker context exactly (no daemon available): a
directory populated with precisely the Dockerfile's COPY list.
before, old COPY set: cargo metadata -> exit 101, the identical error
after, with vendor/: cargo metadata -> exit 0
then all three of the Dockerfile's RUN steps, on 1.95.0, with the image's
RUSTFLAGS="-C target-cpu=x86-64-v3":
cargo build --release Finished, 43.21s
cargo build --release --features jit-native Finished, 45.99s
cargo test --release --lib -- hpc:: 1732 passed, 0 failed
Not verified: an actual `docker build`. No daemon in this environment. The
simulation reproduces the reported failure byte-for-byte and clears it, and it
exercises every RUN line, but it does not cover anything specific to the debian
base image or the apt layer.
Claude-Session: https://claude.ai/code/session_01VdfbkUCBbtZhy3yjSfCDHp
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughDocker build stages are updated to Rust 1.95.0, verify the installed compiler version, copy vendored dependencies for Cargo patch resolution, and report the new version in runtime checks. ChangesRust build image updates
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Two bugs, both pre-existing, the second hidden behind the first.
1 —
vendor/was never copiedThe root manifest has
[patch.crates-io] chacha20 = { path = "vendor/chacha20" }, and both Dockerfiles do a selectiveCOPY—Cargo.toml,crates/,src/,examples/,benches/— that never includedvendor/.Cargo resolves
[patch]entries while loading the manifest, before features and before target selection. So this isn't a link-time miss; the build dies at parse:vendor/chacha20is tracked (18 files), isn't gitignored, and.dockerignoredoesn't excludevendor/— the directory was simply never listed. The patch arrived in2539cadwithout the Dockerfiles being updated alongside it.This is the same failure class as the
examples//benches/comment already in the file — which exists because this happened once before. A selective-COPY Dockerfile has to be updated whenever a path source is added to the manifest, and the new comment says so explicitly.2 — The image pinned rustc 1.94.0 for a crate that requires 1.95
Cargo.toml:6rust-version = "1.95"rust-toolchain.tomlchannel = "1.95.0"Dockerfile:24This would have been the very next failure after fixing (1), and was invisible until then.
rust-toolchain.tomlis deliberately not copied into the image — rustup would fetch a second toolchain at build time — so the Dockerfile pin is the only thing keeping the image in step with the repo. There's now a comment saying that and telling the next person to bump it when the toolchain moves.Verification
No Docker daemon in this environment, so I reproduced the context exactly: a directory populated with precisely the Dockerfile's
COPYlist.cargo metadata→ exit 101, the identical errorvendor/cargo metadata→ exit 0Then all three of the Dockerfile's
RUNsteps, on 1.95.0, under the image'sRUSTFLAGS="-C target-cpu=x86-64-v3":cargo build --releasecargo build --release --features jit-nativecargo test --release --lib -- hpc::Not verified: an actual
docker build. The simulation reproduces the reported failure byte-for-byte, clears it, and exercises everyRUNline — but it does not cover anything specific to the debian base image or the apt layer.Generated by Claude Code
Summary by CodeRabbit