fix(developer-rust): let the build cache live on a dedicated volume - #82
Merged
Conversation
hyperi-rust-cache-prune refuses a pool outside the platform cache directory, and a systemd unit never loads the profile that would set XDG_CACHE_HOME. On a box that keeps its caches on their own volume, both prune units would exit 1 on every run. Both tools now take --cache-root, and the role passes rust_cache_root to each so they agree. Empty keeps today's behaviour: ~/.cache, or ~/Library/Caches. The confinement is kept rather than loosened -- it still refuses a pool outside the root, that root is just no longer assumed to be under home.
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
1 participant
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.
hyperi-rust-cache-prune refuses a pool outside the platform cache directory, and a systemd unit never loads the profile that would set
XDG_CACHE_HOME. On a box that keeps its caches on their own volume - desktop-derek has a 512G/cache- both prune units would exit 1 on every run, silently leaving the pool unbounded.Both tools now take
--cache-root, and the role passesrust_cache_rootto each so they cannot disagree. Empty keeps today's behaviour exactly:~/.cache, or~/Library/Cacheson macOS.The confinement is kept rather than loosened. It still refuses a pool outside the root - that root is just no longer assumed to sit under home. A wrong
--cache-rootstill gets a refusal, now with a message naming the right flags.Verified on desktop-derek with
-e rust_cache_root=/cache:build-dir = "/cache/hyperi-rust-build/{workspace-path-hash}"--cache-root /cache/cache/hyperi-rust-buildinstead of refusing, and itsautoceiling correctly derives 85.3G from the 511.7G /cache volume rather than from the root diskAlso restored that box's Rust while I was there:
~/.rustupwas a dangling symlink to/cache/rustup, a directory lost when the volume was rebuilt on 26 Aug, so every rustup call had been failing since. That is box state, not code - but it is what exposed the fail-open bug fixed in #81.Not done here: sccache and ccache still sit at their own defaults under home. The role leaves cache locations alone on purpose, since repointing them on a populated box orphans the old cache rather than capping it. Worth a separate look if you want the whole Rust cache on
/cache.run-tests.shgreen, 55 tests.