toolkit: cache trying to use git for windows' tar.exe on self-hosted runner, failing to find correct gzip
On a self-hosted Windows runner, I just noticed that caches are failing now with errors like:
"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tgz --exclude cache.tgz -P -C C:/runner/_work/msys2-autobuild/msys2-autobuild --files-from manifest.txt --force-local -z
/bin/sh: line 1: gzip: command not found
/usr/bin/tar: cache.tgz: Cannot write: Broken pipe
/usr/bin/tar: Child returned status 127
/usr/bin/tar: Error is not recoverable: exiting now
Warning: Failed to save: "C:\Program failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2
Caches used to work fine, using the version of tar.exe in system32. My understanding is that the programs in git for windows usr\bin are supposed to be regarded as internal to Git for Windows and should not be relied upon by external things like this. @dscho?
Current theory is that Git for Windows’ tar is looking on the path for gzip, either not finding it in my case, or in other cases finding one incompatible with that tar (due to being based on a different Cygwin).
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 28 (2 by maintainers)
Commits related to this issue
- Unset MSYS env everywhere See https://github.com/actions/toolkit/issues/1311 — committed to msys2/msys2-autobuild by lazka a year ago
- Downgrade @actions/cache Due to https://github.com/actions/toolkit/issues/1311 — committed to lazka/setup-msys2 by lazka a year ago
- Downgrade @actions/cache Due to https://github.com/actions/toolkit/issues/1311 — committed to msys2/setup-msys2 by lazka a year ago
I’ve just downloaded the latest version from the FB repo, put it in the custom folder and added to the
PATH
env variable.if I cared about the cache, I’d put zstd.exe on the
PATH
on my runnerthe reason this doesn’t happen on the github-hosted runners I think is because they have a zstd.exe on the PATH. Doing that would probably take care of it. What’s buggy is the supposed fallback case when zstd is not present and it should use gzip, it doesn’t take into account that GNU tar looks for gzip on the PATH too, rather than being linked in like in the bsdtar that it used to use from Windows\System32. There is a gzip.exe, right next to the tar.exe this code took the effort to track down inside Git for Windows, but it is not on the PATH, they should pass the full path to gzip.exe to tar most likely.
does anybody have fixed this warning with gzip in their self-hosted servers with Windows?
@dscho I’ll check this as soon as I can, thank you! There’s probably going to be some delay – I’ve had some urgent personal issues come up that have taken priority over a lot of my life – but it’s on my to-do list.