Emit a warning instead of a silent failure when zstd is missing

[dekimsey]

Issue

I recently attempted to save and restore a cache between my self-hosted OSX runners and the GH-hosted ones. However I was unable to get this working, as I receiving a key not found error.

Background

It came down to the fact that the compression tool is a hidden flag on the cache (the "version"). Which I had a lot of trouble discovering (UI, API calls, error messages, or default logs).

Only when I executed both the save and restore with debug logging enabled was I able to determine zstd was missing on my on-premise hosts.

Examples: On-premise save logs:

##[debug]Checking zstd --quiet --version
##[debug]Unable to locate executable file: zstd. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

vs. GH-hosted restore logs:

##[debug]Checking zstd --quiet --version
##[debug]1.5.5
##[debug]zstd version: 1.5.5

This is with enableCrossOsArchive enabled on both sides.

Request

To make this kind of failure more obvious to users, I'd like to propose:

• Warn on missing zstd, it seems to be the suggested/desired compression tool on all OS's by the action.
• Log if there are other cache hits for this key that were skipped due to incompatible versions (perhaps message is sensitive to the state of enableCrossOSArchive?).

While I now understand how we got this happened, I'd like to make sure others in the future are more easily able to understand and address the issue.

Thank you!

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[dekimsey]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

Still valid

[leofang]

This is very hard to debug and reason about without turning on the debugging log and understand the internal of cache save/restore. The fact that there is a silent fallback when zstd is not found is really error-prone. Since zstd is guaranteed available on GH-hosted runners, it should be the default and the cache action should just fail on self-hosted runners that do not have zstd. We're installing this manually anyway, might as well save us a few hours of debugging...

[leofang]

xref: https://github.com/actions/cache/issues/1455