Cache action shouldn't use first `tar` on the path

The save and restore steps use the first tar on the path: https://github.com/actions/cache/blob/4809f4ada49f99628c256b84f23798ced8214a3c/src/save.ts#L64

This can cause problems if another step modifies the path so that a different version of tar is found first. For example, in this workflow, I installed R and Rtools, which added C:/Rtools/bin to the path. There is a copy of tar.exe in there, as well as gzip.exe. However, when actions/cache tries to use tar, it errors out saying it can’t find gzip. I’m not sure why exactly that error happens, since gzip is in the same directory. But it seems to me that actions/cache shouldn’t even try to use that copy of tar in the first place – it should always use the same copy of tar, no matter what other steps are used in the workflow.

Here’s the error:

Post job cleanup.
C:\Rtools\bin\tar.exe -cz --force-local -f d:/a/_temp/96241c04-a852-4c66-8b28-aae83ff432c1/cache.tgz -C d:/a/_temp/Library .
tar (child): gzip: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
/Rtools/bin/tar: d\:/a/_temp/96241c04-a852-4c66-8b28-aae83ff432c1/cache.tgz: Cannot write: Broken pipe
/Rtools/bin/tar: Child returned status 2
/Rtools/bin/tar: Error is not recoverable: exiting now
[warning]The process 'C:\Rtools\bin\tar.exe' failed with exit code 2

https://github.com/wch/gha/commit/b407b89c2865433ae99dc88f39830437cbd01887/checks?check_suite_id=346434710#step:22:8

[pdotl]

Hi @wch @sammcj we are tracking this issue in #984. Please check the current proposal there and provide comments/feedback if any. Closing this as duplicate and tagging wontfix for doing any path related changes according to the current proposal.

[mzabaluev]

I think using tar from $PATH is non-workable in the long run. Not only you get all the problems associated with system-installed tar binaries: https://github.com/actions/virtual-environments/issues/2619, #301, #362, https://github.com/actions/toolkit/issues/479, to reference just a few, you invite trouble from any workflow that has overridden the path.

I think the right course of action is to settle on using GNU tar in every virtual environment, as it has proven to be the least problematic tar flavor on both Windows and Mac, and is already the default on Linux, and invoking the GNU tar binary by the absolute path. GNU tar is already provided in all three virtual environments supported by GitHub Actions.