Fix CI clippy failure by caching ~/.rustup/toolchains#3
Conversation
sij411
left a comment
sij411
left a comment
There was a problem hiding this comment.
Previously I thought caching ~/.rustup/toolchains would be enough, because clippy is stored as a rustup component under the toolchain directory. But after looking at common Rust CI patterns, I think explicitly installing/selecting the required Rust components is cleaner. The cache should optimise CI speed, not decide whether clippy exists. What do you think? I want to hear your opinion on this.
|
@sij411 The cache miss case is actually fine. When there's no mise cache, mise does a full fresh install and downloads all 7 components including clippy. The failure only happens in a specific half-cached state: the mise cache hits (restoring only the symlink in ~/.local/share/mise), but ~/.rustup is absent. mise sees the symlink, assumes the toolchain is already installed, and skips running rustup. rustup then lazily installs just the 3 minimal components (rustc, rust-std, cargo) when The fix eliminates that half-cached state rather than relying on cache presence to supply clippy. Both cache keys are tied to I agree the real fix belongs upstream in mise: it should either cache ~/.rustup/toolchains alongside ~/.local/share/mise, or check that the symlink target actually exists before skipping installation. That's being tracked in jdx/mise-action#215, but it's out of scope here. |
Previously, jdx/mise-action cached only ~/.local/share/mise, which stores a symlink to the actual rustup toolchain in ~/.rustup. On a cache hit, mise saw the symlink and skipped reinstallation, leaving ~/.rustup empty. rustup then lazily installed only 3 minimal components (rustc, rust-std, cargo) when cargo first ran, omitting clippy — causing `cargo clippy` to fail. The fix adds an actions/cache@v5 step to also cache ~/.rustup/toolchains, keyed on the OS and a hash of mise.toml. On a warm cache the full toolchain (including clippy) is restored before mise-action runs, so mise finds both its symlink and the real files intact. To force-invalidate the rustup cache, bump the key prefix from rustup-v1 to rustup-v2. For the mise cache, pass cache_key_prefix: mise-v2 to jdx/mise-action, or use: gh cache delete --all --repo fedify-dev/feder Assisted-by: Claude Code:claude-sonnet-4-6
|
Also amended the commit to add a comment in .github/workflows/main.yaml above the cache step, linking to jdx/mise-action#215 for future reference. |
|
That was a upstream bug, got it. Thanks for investigating! |
2 participants
jdx/mise-action@v4caches ~/.local/share/mise, which is where mise stores a symlink to the actual Rust toolchain in ~/.rustup. On a cache hit, mise restores the symlink but never touches ~/.rustup itself, sees the symlink, concludes the toolchain is installed, and skips runningrustup. Whencargoruns next, rustup lazily installs the toolchain with only its three minimal components (rustc, rust-std, cargo), omitting clippy.cargo clippythen fails.The fix adds an
actions/cache@v5step to cache ~/.rustup/toolchains, keyed onrustup-v1-{runner.os}-{hash of mise.toml}. With the full toolchain present before mise-action runs, mise finds both the symlink and the files it points to, and no lazy reinstall occurs.This didn't reproduce locally because clippy was already installed as part of the local Rust setup, making the missing-component path unreachable.
To force-invalidate the rustup cache later, bump the key prefix from
rustup-v1torustup-v2in .github/workflows/main.yaml, or delete the cache directly withgh cache delete.This pull request was diagnosed and written with Claude Code (Claude Sonnet 4.6).