Cache save fails with Cygwin in PATH #1073
Comments
This pre-dates the problems introduced in v3.2.1, reported at actions/cache#1073.
|
Having the same issue on my self hosted runner. Tar.exe is running from C:\Program Files\Git\usr\bin\tar.exe instead of C:\Windows\System32\tar.exe since #1039. I tried adding C:\Windows\System32 to PATH but didn't help either. Fail log:
Previous passing log:
|
That version was before the changes causing the issue described in actions/cache#1073 were merged again.
That version was before the changes causing the issue described in actions/cache#1073 were merged again.
* .github/workflows/make.yaml (cygwin): Recent changes to the cache action made it incompatible with Cygwin. See also: actions/cache#1073 Revert to a version of the action that was still working with Cygwin.
|
@Phantsure @pdotl |
|
Dirty workaround as last step: - name: Remove cygwin/msys2 tar binaries
shell: bash
run: |
# https://github.com/actions/cache/issues/1073
rm -rfv \
/usr/bin/tar \
"/cygdrive/c/Program Files/Git/usr/bin/tar.exe" |
|
@sebthom sadly I'd rather use GNU tar if possible: I'm not sure if it's because it's using zstandard over gzip, or just that Windows' tar implementation is less performant, but I've found it to be much more efficient based on my not-yet-very-scientific testing using the |
|
@sebthom thanks, this worked for me. Once it did not find "C:\Program Files\Git\usr\bin\tar.exe", it had to fall back to "C:\WINDOWS\System32\tar.exe" |
See: actions/cache#1073 We rather invoke pacman in its absolute location.
See: actions/cache#1073 We rather invoke pacman in its absolute location.
See: actions/cache#1073 We rather invoke pacman in its absolute location.
See: actions/cache#1073 We rather only add this path locally when we invoke pacman.
See: actions/cache#1073 We rather only add this path locally when we invoke pacman.
…_VER Do not add the MSYS /usr/bin PATH globally because it disrupts the cache action, see: actions/cache#1073 Only add this path locally for calling pacman. The /mingw64/bin PATH is benign; we add it globally so pkg-config can be invoked anytime (directly and from cabal). We use pkg-config (rather than uconv) to get the ICU version.
…_VER Do not add the MSYS /usr/bin PATH globally because it disrupts the cache action, see: actions/cache#1073 Only add this path locally for calling pacman. The /mingw64/bin PATH is benign; we add it globally so pkg-config can be invoked anytime (directly and from cabal). We use pkg-config (rather than uconv) to get the ICU version.
|
I hope that this is no longer an issue, since Git for Windows v2.39.2 shipped with a fix that is supposed to prevent its MSYS2 runtime from trying to use Cygwin's cygheap. If it still is an issue, could you test replacing the |
|
I re-ran the workflow used by author: https://github.com/Phantsure/macos-cache-slowness/actions/runs/4301183995 Thanks @dscho |
* .github/workflows/make.yaml (cygwin): Recent changes to the cache action made it incompatible with Cygwin. See also: actions/cache#1073 Revert to a version of the action that was still working with Cygwin.
Uh oh!
There was an error while loading. Please reload this page.
Hello!
Currently, this action will fail to store a cache on a Windows runner that has Cygwin binaries installed and in the PATH. I've produced a simple repository reproducing the problem on GitHub runners, at https://github.com/me-and/repro-cygwin-cache-woe, where the error is as follows:
(That's taken from this run on the main branch)
The issue appears to be that the action (and the cache code in general) is hard-coded to use the version of
tarthat's included with Git for Windows, but it isn't hardcoded to only use all the libraries and so forth thattarneeds from the same place. If I install an old version of Cygwin – specifically one using the same old version of the cygwin1.dll library that Git for Windows is still based on – things start working again.Bisecting the failure shows the problem was introduced at 9b0be58.
This seems plausibly related to actions/toolkit#1311, which is the same error, and presumably has a similar trigger, but which is apparently not caused by Cygwin being in the PATH.
The text was updated successfully, but these errors were encountered: