caching & reuse
Why dependency caches, compiler outputs and warm build state avoid different work.
For: Advanced: Rust build caching
Rust build caches hold different kinds of state. Whether that state can be reused depends on the requested work and its inputs. This explanation assumes familiarity with Cargo toolchains, features, profiles and cold versus warm builds; Rust CI basics introduces those concepts.
compatibility
Sorus aims to avoid repeating Rust work when the inputs are compatible. A prior output is usable only when it preserves the requested build or test behavior and has a verifiable record of how it was produced.
A source, toolchain, feature or profile change can make previous work unsuitable. Cache availability alone therefore does not establish that a particular job can skip that work.
reuse mechanisms
Dependency locality keeps dependency data near the execution environment. It reduces dependency retrieval; it does not mean compilation was skipped.
Compiled-result reuse reuses compatible compiler outputs. Tenant-scoped reuse is implemented in source. Customer availability depends on release qualification.
Private warm build state retains state between related executions. It is still in development and is not an available beta feature at this documentation revision.
Public dependency data and private build state have separate access rules. Shared dependency data does not imply that customer-produced outputs are reused across tenants.
measuring reuse
A timing alone does not identify which reuse mechanism helped. That requires a record of the enabled mechanism, compatibility checks and observed hits or misses. Missing telemetry leaves the cache behavior unknown.
Cold and warm runs answer different questions. Misses, errors and regressions remain part of the result, so a selected cache hit cannot represent every run. The benchmark method explains how to keep those conditions separate.