[BUG] Using tar on Windows should call `$env:WINDIR/System32/tar` and not the Git bash provided `/usr/bin/tar`

[cderv]

Describe the bug

Recent change introduced the use of tar on Windows

• Use .tar.gz files where available for faster win install #171

Currently, it is calling tar through PowerShell using the program name only, thus relying on PATH resolution.

It happens that /usr/bin/tar is used (probably from Git Bash) and not the Windows internal $env:WINDIR/System32/tar.exe.
This is known to happen on github action (at least encountered in the past)

• The PATH has changed on Windows, and the Git shell tar is used instead of Windows tar actions/runner-images#480

I encountered this because by modifying temp folder to be {{ runner.temp }} on Windows, it leads to having tar dealing with Windows path name with network drive letter. Only Windows's tar can handle that.

This is the issue I encountered using setup-julia action

$ Run julia-actions/setup-julia@v1.9.5
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "tar xf D:\a\_temp\f585e5f8-9502-4dc6-9544-d8ebf784ca06 --strip-components=1 -C C:\hostedtoolcache\windows\julia\1.10.0\x64"
/usr/bin/tar: Cannot connect to D: resolve failed
Error: The process 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe' failed with exit code 1

• This shows that /usr/bin/tar is the own throwing the error
• The error is linked to network drive letter. It happens because in my context, Temp folder is modified to use {{ runner.temp }} which is on D: and it tries to untar on C:.

To Reproduce

I can create a simple example reproducing the Can't connect error but this is not the main issue I would like to report here. I believe any action using 1.9.5 is calling the /usr/bin/tar instead of Window's tar.exe

If you would like a workflow file anyway, I can provide.

Expected behavior

Windows' own tar is used when using tar on Windows, which allows to correctly handle Windows paths.

This change ensures it is, and it solves issue I encountered

diff --git a/dist/index.js b/dist/index.js
index 74d0f94..8acd5f4 100644
--- a/dist/index.js
+++ b/dist/index.js
@@ -268,7 +268,7 @@ function installJulia(dest, versionInfo, version, arch) {
                 }
                 else {
                     // This is the more common path. Using .tar.gz is much faster
-                    yield exec.exec('powershell', ['-Command', `tar xf ${juliaDownloadPath} --strip-components=1 -C ${dest}`]);
+                    yield exec.exec('powershell', ['-Command', `& "$env:WINDIR/System32/tar" xf ${juliaDownloadPath} --strip-components=1 -C ${dest}`]);
                 }
                 return dest;
             case 'darwin':

(I modified in Fork in dist by convenience for testing.

Screenshots/Build logs

With current 1.9.5

With a fork using Windows' tar

Additional context

Nothing more I can think of.

Happy to provide anything more needed. Please do tell me.

Thanks

[cderv]

More detailed information about this issue as more tests show that this is not linked to a change of temporary directory.
In fact, on github-hosted Windows runner, the default will always be on two drives and does not depend on TEMP env var

• RUNNER_TEMP will be in D:
• hostedtoolcache will be in C:

This means that currently, this action requires a tar that can handle Windows paths on two drives

setup-julia/dist/index.js

Line 271 in a1561e9

yield exec.exec('powershell', ['-Command', `tar xf ${juliaDownloadPath} --strip-components=1 -C ${dest}`]);

More detailed answer in #206 and #207

I would sum up this issue this way.

• Using a tar.exe that handles Windows paths with Drive later is required.
• This action will use the first tar on PATH
• Users need to insure the right tar is on PATH (it happens other actions can modify $GITHUB_PATH and mess this up)
• If not, a workaround is to add the tar.exe that works first on PATH before running setup-julia

[ViralBShah]

#206