use windows tar, not git bash one
Fixes https://github.com/julia-actions/setup-julia/issues/205
One where we delete/rename the system tar?
Users may have custom self-hosted Windows runners. In those cases, currently users can specify which tar is used by manually adding it to the front of the PATH before setup-julia is run.
However, after this PR, the user cannot control which tar is used. Could we add an escape hatch? Maybe an action input that allows the user to specify the desired tar? And then if the user doesn't specify that action input, we fall back to this hardcoded "$env:WINDIR/System32/tar"?
In those cases, currently users can specify which tar is used by manually adding it to the front of the PATH before setup-julia is run.
This could definitely be a solution to avoid the issue from #305 - though I still think defaulting to tar.exe from Windows if it exists would be better.
Could we add an escape hatch? Maybe an action input that allows the user to specify the desired tar? And then if the user doesn't specify that action input, we fall back to this hardcoded "$env:WINDIR/System32/tar"?
Selecting the right tar could be a good escape hatch - it could also be through an environment variable maybe, which is less user-facing maybe.
Are custom self-hosted Windows runners using a different tar.exe?
For the new context, I found the real why about #205 (detailed in https://github.com/julia-actions/setup-julia/pull/207#issuecomment-1893545245)
The real problem was that another action was changing the PATH internally tweaking $GITHUB_PATH. This led to the wrong tar being used - by wrong I mean a tar binary that does not handle the untar from D: to C:
Currently, julia-actions/setup-julia use any tar from PATH, including any that could be incompatible with the expected command
https://github.com/julia-actions/setup-julia/blob/a1561e938c17e7aaf8236334d6d533e774c71dcd/dist/index.js#L271
-
juliaDownloadPathwill be inD:as it is based onRUNNER_TEMPby default throughtc.downloadTool()https://github.com/julia-actions/setup-julia/blob/a1561e938c17e7aaf8236334d6d533e774c71dcd/dist/index.js#L234-L236 -
destwill be a folder in thehostedtoolcachefolder onC:https://github.com/julia-actions/setup-julia/blob/a1561e938c17e7aaf8236334d6d533e774c71dcd/dist/index.js#L429-L439
So to be safer there could be two solutions at least :
- ensuring either the right tar (like in this PR + a potential option) or
- ensuring the same drive is used calling
tc.downloadTool()with a non defaultdest.
Thanks a lot.
ensuring the same drive is used calling
tc.downloadTool()with a non defaultdest.
I unfortunately don't think that we'll be able to guarantee (in this action) that the same drive is used. I think we need to default to the Windows system tar.
Alternatively, we could go with this PR for now, and then add an escape hatch later.
Ugh, just because I added a comment, we now need to re-run npm run build and check in the results.
I will do that in a little bit, unless someone beats me to it.
macos-11 failures are because of a GitHub brownout. See also https://github.com/julia-actions/setup-julia/pull/251
I will make a new tag and release.
Okay, CI is all green on the release/v2.1.0 branch.
Branch: https://github.com/julia-actions/setup-julia/tree/releases/v2.1.0
Commit: https://github.com/julia-actions/setup-julia/commit/81d42b556a18b0d67455a742fcbffdeb49b3ffb0
I've pushed the new tags.
https://github.com/julia-actions/setup-julia/releases/tag/v2.1.0
https://github.com/julia-actions/setup-julia/releases/tag/v2.1
https://github.com/julia-actions/setup-julia/releases/tag/v2
https://github.com/julia-actions/setup-julia/releases/tag/latest