tar.exe: Option --force-local is not supported

[selsta]

2020-01-16T23:42:29.5975444Z ##[group]Run numworks/setup-msys2@v1
2020-01-16T23:42:29.5975620Z with:
2020-01-16T23:42:29.5975728Z   msystem: MINGW64
2020-01-16T23:42:29.5975803Z ##[endgroup]
2020-01-16T23:42:31.5840340Z [command]C:\windows\system32\tar.exe -x -J --force-local -C d:/a/_temp/msys -f d:\a\_temp\b4c13a67-cdc5-4b00-af55-65efdff10161
2020-01-16T23:42:31.6488883Z tar.exe: Option --force-local is not supported
2020-01-16T23:42:31.6489770Z Usage:
2020-01-16T23:42:31.6491863Z   List:    tar.exe -tf <archive-filename>
2020-01-16T23:42:31.6505339Z   Extract: tar.exe -xf <archive-filename>
2020-01-16T23:42:31.6506336Z   Create:  tar.exe -cf <archive-filename> [filenames...]
2020-01-16T23:42:31.6506609Z   Help:    tar.exe --help
2020-01-16T23:42:31.6529347Z ##[error]The process 'C:\windows\system32\tar.exe' failed with exit code 1
2020-01-16T23:42:31.6674648Z ##[error]Node run failed with exit code 1
2020-01-16T23:42:31.6704739Z Cleaning up orphan processes

Example of this happening: https://github.com/monero-project/monero-gui/commit/fae5956bfbbe81256304eeeca24d0a8a51ca08bb/checks?check_suite_id=405350921

Same workflow used to work 2 days ago.

[Ecco]

Hmm, something must have changed upstream (i.e. in the default windows setup used by GitHub actions). I think they might have switched to BSD tar.

Given actions/toolkit#165 has been closed, maybe we could simply try and use tool-cache?

[eine]

This was broken by an update that GitHub deployed to the VMs some hours ago. There is little we can do on our side. See actions/runner-images#282.

[eine]

It is possible to work around it using 7z instead of tar: msys2/setup-msys2@7ade64a

[Ecco]

Great idea too! My advice on this would be:

1. If possible, just use tool-cache
2. If not, use 7z

What do you think?

[eine]

I agree. However, I think that using tool-cache is independent from replacing tar with 7z.

The issue now is that tar is not resolved properly. This is because multiple versions exist in the PATH and modifications by GitHub can break it (as it happened some days ago). Replacing it is expected to be more stable because AFAIK the interface of 7z is consistent.

Apart from that, until now we have been downloading the tarball each time. Since we are already using the tool-cache package to download it, it'd be interesting to use it for caching too. However, I don't know what should be cached: the tarball? the cleanly extracted tarball? the content of msys64 after the first execution? That's why I think it should be discussed in a separate issue.

[Kha]

I would like to make sure that projects depending on this action are unblocked as soon as possible. Would it be reasonable to implement a simple switch to tool-cache for now and worry about 7z and caching later? Would you appreciate a pull request? No promises from my side though :) .

[eine]

@Kha, the single-line modification in msys2/setup-msys2@7ade64a works. It is already implemented and published in eine/setup-msys2@v0 (which is working ok, as you can see in https://github.com/ghdl/ghdl/runs/400285693). I'd be interested on seeing a PR to use caching features of tool-cache; but, as said, I don't know what does it have to do with fixing the method to extract a .tar.xz file.

[Ecco]

@eine my idea was that tool-cache supposedly has support for un-taring a file, so we might as well rely on this.

When I first wrote that extension, tool-cache just couldn't extract tar files on Windows. I suggested a PR that was rejected for another supposedly better one. Turns out, the latter just doesn't seem to work at all. What a joke 😄

Anyway, sounds like once again we're on our own to work around trivial upstream issues…

@eine , would you be so kind as to create a PR with your 7z-based fix? Thanks so much!

[Ecco]

Ok, it's fixed. Thanks @eine !