Cache saving is best-effort, restoring cache is not

I stumled upon this bug while using self-hosted runners.

Background

Cache version is derived with the compression tool in mind. So an identical file can be compressed with zstd or gzip, and that would yield two different cache entries (despite the file being identical!). This is expected and well-documented, but:

When you save the cache, on linux-x86_64, the action optimistically chooses zstd as the compression method. If it can't find zstd on the host, it downgrades to gzip. If it can't find gzip too, it fails to save the cache.

When you restore the cache, on linux-x86_64, the action optimistically expects zstd as the compression method. If it can't find zstd on the host, it downgrades to gzip. If it can't find gzip too, it fails to restore the cache.

The issue

Let's say we have two runners: Saver and Restorer. Saver only has gzip, so it caches the file with gzip. Restorer has both zstd and gzip, BUT it fails to restore the cache, because, seeing that zstd is available, it expects the cache to also be zstd-compressed. Seeing that there is no zstd-compressed cache (because Saver doesn't have zstd), it doesn't even try to check if there's gzip-compressed cache and says there is no cache at all.

Seeing that not all Linux distributions provide zstd out of the box (especially older ones), this little caveat can take a lot of manhours to debug: it really is not trivial to trace.

Solutions

• Allow specifying the compression method when calling the Action, default to zstd or gzip ONLY
• When restoring the cache, check if there are caches compressed with other methods too; don't just fail if there's no zstd cache
• Decouple the "compressed with" metadata from the cache version: that way, the action will be able to see that there is matching cache, and it will see the metadata that the cache encrypted with gzip, so it will only fail if gzip is not installed; this will also provide a very nice and clear error message for debugging

Start by tracing the Linux x86_64 compression selection in the save and restore paths described in the issue, focusing on how zstd and gzip availability affect cache lookup. Compare the proposed approaches and define done as restoring a gzip-compressed cache when zstd is available, with a clear failure only when the required compressor is unavailable.