Do not fallback on caches from other cache groups

[BD103]

Closes #22.

Objective

Github Actions Caches have the ability to "fall back" to multiple caches, if the created cache key is not found. This is by setting the restore-key input, and let's us still use caches with outdated Cargo.lock and Cargo.toml files, as well as other cache groups.

This is an issue, because often cache groups do not do the same work. Let me give an example:

You have two jobs: one that runs cargo check and another that runs cargo test. Both have different cache requirements.

1. cargo check does not need to compile anything, so it generates less files. As a result, its cache is smaller, meaning that it downloads faster.
2. cargo test does need to compile into binaries, so it generates a lot more files. It's cache is larger, but that's fine because it uses the entire cache.

If we let the cache action fallback across multiple different jobs, cargo check could download cargo test's larger cache. Then, when cargo check saves a new cache, it contains all of the unnecessary binaries that cargo test generated, increasing the cache size and download time.

Solution

Prevent separate cache groups from sharing caches by removing the final restore key.

[TimJentzsch]

Awesome, thanks!

[TimJentzsch]

The question is now: Does this warrant v3 or can we stay v2?

[alice-i-cecile]

I think v2 is fine; can you add a tag?

[BD103]

The question is now: Does this warrant v3 or can we stay v2?

I don't think this warrants v3. The only reason you would depend on this behavior is to share caches, but that's what cache groups are for.