Moving to virtual-environments since VM changes broke this.
@alepauly can you verify that this is fixed? ty!
@thechrisjohnson, the MWEs above are still failing/stuck: https://github.com/eine/setup-msys2/runs/417809983
@thejoebourneidentity @eine the issue is already fixed, but the VM image is not deployed yet. It should be available in a week or two.
@eine the image has been deployed. Could you check the behavior, please?
@miketimofeev I restarted an old job, and I also pushed some new. In all cases, runs are still stuck:
@eine thanks for the update, we will continue the investigation
@eine I'm able to reproduce it. Could you give an example of a successful build with untar?
@eine I'm able to reproduce it. Could you give an example of a successful build with untar?
I'm not sure I understand what you mean. The following commit shows what was used in setup-msys2 before something broke upstream, and how it was fixed using 7z instead: https://github.com/numworks/setup-msys2/commit/b3452aa847865e86d92d65d049cef96a52ab6418 Then, I tried all the examples above, none of which did work. Is using untar different from any of those?
Note that I am ok with using 7z. Furthermore, I hope #342 to be merged soon. Therefore, I don't have any actual build where I need to use tar or untar.
@eine sorry for confusing, I mean successful setup-msys2 with tar -xJf. But it looks like we've already found the root cause - default windows tar.exe(C:\windows\system32tar.exe) is used instead of tar comes along with Git and that "Windows tar" can't extract from such xz archives. We're working on getting back Git tar.exe to PATH.
@miketimofeev, please, note that this is not the first chapter in the series of "conflicts between multiple installed versions of tar". I do think that the decision to make BSD's tar the default instead of Git for Windows' (MINGW's) was on purpose. See actions/toolkit#165. Precisely, the action (MWE1 above) is expected to handle diferences between versions of tar. Moreover, if/when MSYS2 is installed (see #30 and #342) the environment might change, as it would be sensible to replace Git for Windows' tar with MSYS2's.
@eine yeah, we're still working on the best way to deliver MSYS2, so it's just a question of time. I've made this PR to fix that particular issue until MSYS2 isn't delivered.
https://github.com/actions/virtual-environments/pull/415
@eine PR has been merged. I will let you know when new image is available
@eine, unfortunately, this git tar breaks more than fixes. We have to roll back the changes. Please use 7z or consider adding C:\Program Files\Git\usr\bin to the path before your run.
@miketimofeev, as said, I'm ok with using 7z. However, if tc.extractTar is broken, it should be removed or a warning should be added.
@ericsciple could you take care of tc.extractTar, please?
@eine
if
tc.extractTaris broken
Can you clarify? The function finds tar in the PATH and calls it with the supplied flags (or default if not overridden).
For a .tar.xz file, it sounds like tar uses external tool xz to decompress (also must be in PATH?).
Adding git tar to the PATH for the hosted Windows runner won't fix for folks using self-hosted Windows runners.
If possible, may want to switch to a more common archive format on Windows (zip).
Other options might be:
git using io.which, and then use relative path to effectively add C:\Program Files\Git\usr\bin to the PATH before calling extractTar.io.which to locate 7z, and downloading/caching if not found. Also could try 7zdec.exe which is very small. If it handles the file format then could carry that file with your action. It's what tool-cache uses for extract7z@ericsciple, It seems to be fixed now. 麓extractTar麓 fails, as expected: https://github.com/eine/setup-msys2/runs/481303190?check_suite_focus=true