In actions/cache#465, the user's workflow was modifying the PATH while installing some custom software. This changed the tar implementation found when searching the PATH because it added C:/Program Files/Git/usr/bin. This broke caching since the cache action expected to use "BSD tar with GZip" during the restore step but would save the cache using "GNU tar with Zstd".
There is already work underway to always use GNU tar (when available), but even this could potentially run into issues if:
- The user modifies the PATH env var and removes all
tar implementations - The system starts without
GNU tar but the user installs it in a subsequent step.
It therefore seems like we need the cache to "lock onto" a particular version of tar. My thinking is to record the tar implementation in the state which can then be used in the post step.
In actions/cache#465, the user's workflow was modifying the
PATHwhile installing some custom software. This changed thetarimplementation found when searching thePATHbecause it addedC:/Program Files/Git/usr/bin. This broke caching since the cache action expected to use "BSD tar with GZip" during the restore step but would save the cache using "GNU tar with Zstd".There is already work underway to always use GNU tar (when available), but even this could potentially run into issues if:
tarimplementationsGNU tarbut the user installs it in a subsequent step.It therefore seems like we need the cache to "lock onto" a particular version of
tar. My thinking is to record thetarimplementation in the state which can then be used in the post step.