GitHub Actions / CI. Does it help?

[jleni]

How can Kache help with Rust builds in GitHub Actions and CI caching workflows?

[jleni]

yes, this is one of the clearest wins. In CI you rebuild the same dependency graph constantly across runs and across runners, which is exactly the repeated, shareable workload kache is built for.

The drop-in path: kache-action

There is a GitHub Action, kache-action, that wires everything up for you. It installs the kache binary (with checksum verification), sets RUSTC_WRAPPER so every rustc call goes through kache, and configures storage. No build-script changes, no
RUSTFLAGS juggling.

It supports two backends:

• GitHub Actions cache (default): keyed on kache version, OS, arch, and Cargo.lock hash. Zero setup beyond adding the action.
• S3-compatible (AWS, MinIO, R2, Ceph, and similar): the daemon warm-prefetches artifacts at the start of a job and pushes results with kache sync. This is what gives you sharing across runners, across branches, and between CI and local machines.

Why it helps in CI specifically

• Cross-runner reuse: because kache normalizes paths and env, keys converge across machines, so a fresh ephemeral runner can hit a cache populated by a different runner or even by a developer's laptop.
• Zero-copy restores: hits are materialized by reflink or hardlink, so restoring a warm cache is near-instant on modern filesystems rather than unpacking gigabytes.
• Graceful degradation: if the remote is unreachable it falls back to local, and a local-only mode works with no remote at all, so a cache hiccup never breaks the build.
• Correct by construction: keys are content-addressed, not mtime-based, so CI cannot serve a stale artifact the way a naive shared directory can. That matters most in CI, where one wrong cached object would otherwise spread across the whole fleet.
• Not just Rust: the same flow caches C/C++ (cc/clang) in hybrid projects, so -sys crates and native deps benefit too.

Visibility: the report

The action runs kache report and posts a sticky PR comment plus a job summary on every run, showing hit rate, local vs remote hit counts, miss count, and a breakdown of misses by compile time. So you can see exactly what the cache saved and which
crates are still cold, instead of guessing.

What is improving next

Prefetching already works: the daemon warms likely-needed artifacts at job start. We are building a stronger server-side planner that ranks what to prefetch more intelligently, which raises hit rates and shrinks cold-start time further, especially
on ephemeral runners that begin empty.

To be transparent about priorities: the initial phase deliberately put correctness first, alongside solid Rust and C/C++ hybrid support, rather than squeezing the planner. That foundation is in place and reliable now, and the planner work is where
the next round of CI speedups is coming from.