Warnings in caching steps about run-vcpkg

[lukka]

@TrueBrain right, I even already seen this problem in the past but totally forgot about it.

By reading various open issues, in particular this one on the GitHub runner OS images and this other on @action/cache, the solution is to change the @actions/cache's NPM package to use the GNU tar rather than the BSD one on Windows environments. And also passing in "--force-local" flag.

Whether there is anything sensible that can be done on run-vcpkg until this is fixed upstream, I am open to suggestions.

One potential hack is to rename the BSD tar.exe to anything: running the restore of the cache will then use the GNU one in the Git's bin directory. Then revert the renaming.

[lukka]

@Shatur95 as soon a workaround is found and known to not have side effects, I would then include it in the action.
I'd try by prepending to the path the GNU tar contained in the Git's bin directory.
I haven't yet, anyone can beat me to it and create a PR for making this change :)

[lukka]

@TrueBrain thanks for reaching out! The following is what is happening:

• Once in the past, the cache has been stored successfully.
• Using the same cache key, now the restore of the existing cache partially fails (the binaries files must have been restored in vcpkg/installed, because the execution of vcpkg install tells that everything is installed already).
  The root cause of everything is the failure of tar that returns exit code 1 (rather than 0) and the @actions/cache's restoreCache() API throws an exception, then caught in here by the run-vcpkg action. The latter tries again the cache restore process (this is to minimize network issues, it can be rethought).
• Now the cacheHit flag is set to false, hence the saving of the cache is attempted by run-vcpkg using an (existing) cache key. This attempt fails with a warning about that the "cache key already exists".

Could you please activate on a run the full log so that the log contains more data to reason about?

[TrueBrain]

I can do you one better: your own run also throws the error, and already has debugging on :)

https://github.com/lukka/run-vcpkg/runs/1531747501?check_suite_focus=true#step:4:106

Possibly it has been there for a while, but we never saw it; it is the new GitHub design that highlights this much more :)

If you need us to do a run, just let me know, it really is no problem. But as a developer myself, being able to reproduce issues locally always helps, hence me pointing to your own run. I am hoping that is more useful to you :)

[TrueBrain]

I like how you think :D But honestly, I do not think you should do that in your action; we can do that on the runner. Awesome, happy you found the cause of it, now we can either work around it ourself, or hope they fix it upstream soon :D Tnx!

[Shatur]

Is there a some workaround for it?

[TrueBrain]

When save-cache uses GNU tar, I get this error: tar: c\:\vcpkg: Cannot stat: No such file or directory. Not sure where the extra \ comes from, but I guess the two tars handle manifest files differently :) Have not investigated it further.

[TrueBrain]

So, instead of toying with what tar to use, I considered removing the problem the Windows tar runs into. And that seems to do the trick:

attrib -r "c:\vcpkg\.git\*.*" /s

It is not pretty, and for sure it has to be considered a hack. But it does remove the warning, which was the goal :D

We now just execute this in a separate step before doing run-vcpkg.

[lukka]

In the most recent run of run-vcpkg functional tests and validation tests, I do not see anymore the warning:

"restoreCache() failed again: 'Error: Tar failed with error: The process 'C:\windows\System32\tar.exe' failed with exit code 1'"

which may mean it was fixed on the GitHub environment side. Nothing was changed on run-vcpkg to make the warning to disappear.

Let me know if this problem is still there, I am going to close this until then.