docker-compose.yml mounts /root/.cargo per runner, so the crate registry persists. It does not mount /root/.rustup, which is where rustup keeps the toolchains themselves — ~/.rustup/toolchains/<channel>-<triple>/ with rustc, cargo, the std libs and any requested components.
So on the X64 beelinks a Rust job persists its dependencies and re-downloads its compiler. dtolnay/rust-toolchain (used by setup-stack in dodi-smart/.github) shells out to rustup toolchain install, which is a ~200 MB+ download per job for stable with clippy/rustfmt, and more when a component or a second target is requested.
Two things are worth separating here:
The toolchain is not lost between jobs today. /root/.rustup lands in the container's writable layer, and EPHEMERAL: "false" with restart: unless-stopped means the container survives. So in steady state rustup finds the toolchain already present and the cost is a version check. The real failure mode is docker compose pull && docker compose up -d — every image update recreates the containers and throws the toolchains away, and that is exactly the operation the README tells the host to run.
It is also outside the cap. Same class of problem as #7 from the other direction: because it is in the container layer rather than a named volume, lru_cap cannot reach it even if it were extended, and it grows with every toolchain and target a repo asks for.
Suggested fix, matching the existing per-runner pattern:
- runner-rustup:/root/.rustup
with runner-rustup, runner-rustup-2, runner-rustup-3 in the volumes: block, and a row in the README cache-volume table. Per runner, not shared — concurrent rustup toolchain install runs against one tree is the same corruption risk the file's header comment already calls out for bun and gradle.
If the answer is instead "Rust does not run on these runners often enough to be worth a volume", that is a fine call, but it belongs in the README next to the other five so the omission reads as a decision rather than an oversight. The same question applies to ~/.pub-cache: dodi-smart/.github PR #6 keeps PUB_CACHE job-scoped in every mode specifically because no volume backs it, and that line should be reverted there if a pub volume is added here.
docker-compose.ymlmounts/root/.cargoper runner, so the crate registry persists. It does not mount/root/.rustup, which is where rustup keeps the toolchains themselves —~/.rustup/toolchains/<channel>-<triple>/with rustc, cargo, the std libs and any requested components.So on the X64 beelinks a Rust job persists its dependencies and re-downloads its compiler.
dtolnay/rust-toolchain(used bysetup-stackindodi-smart/.github) shells out torustup toolchain install, which is a ~200 MB+ download per job for stable with clippy/rustfmt, and more when a component or a second target is requested.Two things are worth separating here:
The toolchain is not lost between jobs today.
/root/.rustuplands in the container's writable layer, andEPHEMERAL: "false"withrestart: unless-stoppedmeans the container survives. So in steady state rustup finds the toolchain already present and the cost is a version check. The real failure mode isdocker compose pull && docker compose up -d— every image update recreates the containers and throws the toolchains away, and that is exactly the operation the README tells the host to run.It is also outside the cap. Same class of problem as #7 from the other direction: because it is in the container layer rather than a named volume,
lru_capcannot reach it even if it were extended, and it grows with every toolchain and target a repo asks for.Suggested fix, matching the existing per-runner pattern:
- runner-rustup:/root/.rustupwith
runner-rustup,runner-rustup-2,runner-rustup-3in thevolumes:block, and a row in the README cache-volume table. Per runner, not shared — concurrentrustup toolchain installruns against one tree is the same corruption risk the file's header comment already calls out for bun and gradle.If the answer is instead "Rust does not run on these runners often enough to be worth a volume", that is a fine call, but it belongs in the README next to the other five so the omission reads as a decision rather than an oversight. The same question applies to
~/.pub-cache:dodi-smart/.githubPR #6 keepsPUB_CACHEjob-scoped in every mode specifically because no volume backs it, and that line should be reverted there if a pub volume is added here.