ci: persist cargo caches on runner volume#75
Merged
Conversation
Point CARGO_HOME and CARGO_TARGET_DIR at the runner's persistent volume (/home/runner/runner) instead of the image layer / the git-cleaned checkout. Workflows run actions/checkout, which `git clean`s the checkout's target/ every run; with cargo's caches as siblings of _work on the volume, build output survives both the clean and container recreation. This lets Rust CI (wavekat-voice) drop Swatinem/rust-cache entirely: warmth now comes from on-disk artifacts on the persistent runner rather than tarring ~370 MB and round-tripping it to GitHub's cloud cache on every run. The toolchain binaries stay baked at /usr/local/cargo/bin (still first on PATH) and rustup resolves toolchains via RUSTUP_HOME, so only the registry/git cache and compiled artifacts relocate. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Point
CARGO_HOMEandCARGO_TARGET_DIRat the runner's persistent volume (/home/runner/runner) in the GitHub Actions runner image, instead of the image layer (CARGO_HOME=/usr/local/cargo) and the default./targetinside the checkout.Why
Workflows run
actions/checkout, whichgit clean -ffdxs the checkout'starget/every run. So Rust CI had no warm on-disk artifacts and relied onSwatinem/rust-cache, which tars ~370 MB and round-trips it to GitHub's cloud cache on every run — minutes of upload at a few MB/s on these self-hosted runners (and the wavekat-voice parallel-jobs split doubled it to two caches).With cargo's caches as siblings of
_workon the same persistent volume, compiled artifacts (incl. the 5–10 min ONNX/sherpa build) and the crate registry survive both the git-clean and container recreation. That lets wavekat-voice drop rust-cache (companion PR), eliminating the upload entirely.The toolchain binaries stay baked at
/usr/local/cargo/bin(still first onPATH) and rustup resolves toolchains viaRUSTUP_HOME, so only the registry/git cache and compiled artifacts relocate.Rollout (volume-preserving — keeps registration)
On the runner host (
aoc-m3l):systemctl restartre-execsdocker run --rm … wavekat/gha-runner:latestwith the rebuilt image, so the newENVapplies while thegha-runner-Nvolume (and the runner's registration) persists. Do not re-runsetup-gha-runners-docker.shfor this — it wipes volumes.First CI run per runner after the restart is cold (fresh
cargo-home/cargo-targeton the volume); every run after is warm with zero cache upload.Sequencing
Deploy this before merging the wavekat-voice
cache: falsePR — otherwise that PR's runs go fully cold every run (no on-disk target, no cloud cache).Note
The entrypoint's
chown -R runner:runner /home/runner/runnernow also recurses overcargo-targeton container (re)start — a one-time-ish cost on restart, not per job. Can be narrowed later if it bites.🤖 Generated with Claude Code