If you use this Action on a Windows Self-Hosted Runner, you might run into this error message:
tar.exe: Option --hard-dereference is not supported
Usage:
List: tar.exe -tf
Extract: tar.exe -xf
Create: tar.exe -cf [filenames...]
Help: tar.exe --help
Error: Process completed with exit code 1.
In my case it is due to the fact that when this action calls Bash, it called a Bash that had bsdtar in it, but the --hard-dereference option is only available in GNU tar.
As the documentation for the Workflow Syntax states for the shell parameter bash states, on Windows Systems it will use Bash from Git (or the Git Client / Git-SCM Client). And it does. But Git comes with 2 versions of Bash.
One is installed in C:\Program Files\Git\usr\bin and another one installed under C:\Program Files\Git\bin.
When installing Git on Windows, it puts the C:\Program Files\Git\usr\bin directory into the Systems PATH variable. So whoever starts bash(.exe) gets this one. And this one comes with bsdtar.
If you start bash.exe from C:\Program Files\Git\bin, you get another one that uses GNU tar.
So to fix this, you have to add the C:\Program Files\Git\bin directory to your systems PATH variable and restart the system (or at least th Runner Services). Make sure this Path is ABOVE the one Git created, so it gets picked first.
Calling bash.exe is now starting C:\Program Files\Git\bin\bash.exe and shows me GNU tar.
Bonus: If you happen to have WSL installed on the box with your Self-Hosted runners, make sure the Path to your bash.exe is above the C:\Windows\system32 one. Because with WSL installed, it will pick Bash from your WSL Distribution which leads to other issues if your Runners use the default LocalSystem Account. WSL does not work at all with Local System Accounts.
I hope this helps other people running into the same issue.
If you use this Action on a Windows Self-Hosted Runner, you might run into this error message:
In my case it is due to the fact that when this action calls Bash, it called a Bash that had bsdtar in it, but the --hard-dereference option is only available in GNU tar.
As the documentation for the Workflow Syntax states for the shell parameter bash states, on Windows Systems it will use Bash from Git (or the Git Client / Git-SCM Client). And it does. But Git comes with 2 versions of Bash. One is installed in C:\Program Files\Git\usr\bin and another one installed under C:\Program Files\Git\bin. When installing Git on Windows, it puts the C:\Program Files\Git\usr\bin directory into the Systems PATH variable. So whoever starts bash(.exe) gets this one. And this one comes with bsdtar. If you start bash.exe from C:\Program Files\Git\bin, you get another one that uses GNU tar.
So to fix this, you have to add the C:\Program Files\Git\bin directory to your systems PATH variable and restart the system (or at least th Runner Services). Make sure this Path is ABOVE the one Git created, so it gets picked first. Calling bash.exe is now starting C:\Program Files\Git\bin\bash.exe and shows me GNU tar.
Bonus: If you happen to have WSL installed on the box with your Self-Hosted runners, make sure the Path to your bash.exe is above the C:\Windows\system32 one. Because with WSL installed, it will pick Bash from your WSL Distribution which leads to other issues if your Runners use the default LocalSystem Account. WSL does not work at all with Local System Accounts.
I hope this helps other people running into the same issue.