You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
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.
The text was updated successfully, but these errors were encountered:
In actions/cache#465, the user's workflow was modifying the
PATH
while installing some custom software. This changed thetar
implementation found when searching thePATH
because 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:
tar
implementationsGNU 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 thetar
implementation in the state which can then be used in the post step.The text was updated successfully, but these errors were encountered: