Summary

I found that we have encoutered many large cache files in self hosted buildings.
Example:

... Restoring cache ...
Unable to find cache with primary key: caches/web-infra-dev/rspack/RCache-L-1-x86_64-unknown-linux-gnu-ci-Linux-x64-653aa58b-c74f39d0.
Cache Size: ~3230 MB (3386500790 B)
/usr/bin/tar -xf /home/runner/_work/_temp/3d72c48b-e9e8-4929-8d7f-dbfc1f9ddb8d/cache.tgz -P -C /home/runner/_work/rspack/rspack -z
Cache restored successfully
Restored from cache key "caches/web-infra-dev/rspack/RCache-L-1-x86_64-unknown-linux-gnu-ci-Linux-x64-653aa58b-a594359e" full match: false.

3G sized Cache wastes time to restor and save in CI.

How does the large Cache file Come

The Cargo Cache restore is ussing full match then restore key match two steps.

1. Build A starts with no cache, then generate cache with key Cache-rustool-k1-cargo-toml-key2
2. Build B starts with no cache either, and its full match key is Cache-rustool-k1-cargo-toml-key9, but the full match key related cache doesn't exist; so this build will try to find cache with its restore key which is Cache-rustool-k1-, if any cache key starts with that, it hits.
   2.1 So build A uses cache Cache-rustool-k1-cargo-toml-key2 restores to local, and then generate its cache files and mixed with orginal cache file, then zip and save the new cache with key Cache-rustool-k1-cargo-toml-key9. And its size is inflated.

if step 2 repeats serveral time, the cache will be very large , eg 3G.

How to fix

In self hosted build, we only support full match cache; if no full match find, just build without cache then generate the new cache.

1. add fullmatch-only config in rust-cache action. stormslowly/rust-cache@8269079 , config to true in our workflow.
2. bump Self hosted Cache version to 3, old large caches will vanished in two weeks

Related links

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).