Cache made on Ubuntu works on Ubuntu but fails on windows

[GC-Configit]

Hi, Today I have got the odd error, that when I'm trying to retrieve cache from ubuntu on windows it just fails. When I'm trying to get the same cache on Unbutu - everything works fine. The same YAML code was working yesterday, I even rescheduled that builds and a problem also occurred for them.

I'm using action/cache@v3 some logs are below:

Received 0 of 267052384 (0.0%), 0.0 MBs/sec Received 88080384 of 267052384 (33.0%), 42.0 MBs/sec Received 192937984 of 267052384 (72.2%), 61.3 MBs/sec Received 267052384 of 267052384 (100.0%), 54.4 MBs/sec Cache Size: ~255 MB (267052384 B) "C:\Program Files\Git\usr\bin\tar.exe" --use-compress-program unzstd -xf D:/a/_temp/df67cde0-09e7-4980-809c-f3c3e3712478/cache.tzst -P -C D:/a/mono-repo/mono-repo --force-local tar (child): unzstd: Cannot exec: No such file or directory tar (child): Error is not recoverable: exiting now /usr/bin/tar: Child returned status 2 /usr/bin/tar: Error is not recoverable: exiting now Warning: Failed to restore: Tar failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2

[aparna-ravindra]

Hi @GC-Configit Could you please more information such as

• are you using hosted runner or did the workflow run on self-hosted runner?
• If the workflow is running on a public repo, could you share the link? If not, is it possible to share the debug logs for this step?
• What is the version of the tar used in ubuntu vs windows?

[GC-Configit]

I have found the issue. When I forced actions/github to use @3.0.5 it's working. So I see the issue with the lasted release. For @3.0.5 build is working fine

• I'm using host runner
• I'm not sure if I can provide for you debug logs, I need to ask my management
• I'm using ubuntu-lastest and windows-2022

[vsvipul]

This might have been caused by https://github.com/actions/cache/pull/887 . We are looking into it. Thank you.

[vsvipul]

@GC-Configit Can we get the workflow file (cache relevant parts only) which you are using? Thank you.

[GC-Configit]

#just the step that is used for create cache ${{inputs.CACHE_KEY_BASE}} contains only base part of the key
- name: Cache sub-domain-name
  uses: actions/cache@v3
  with:
    key: ${{inputs.CACHE_KEY_BASE}}-sub-domain-name
    path: test-binaries/sub-domain-name

And code below is running both on Ubuntu and windows to get the cache generated in step above. On Ubuntu everything is fine but on windows it started crashing after your last release

- if: ${{ runner.os == 'Windows' }} # Workaround required when using cache action across operating systems. See https://github.com/actions/cache/issues/591
 name: Use GNU tar not BSD tar
 shell: cmd
 run: |
   echo "Adding GNU tar to PATH"
   echo C:\Program Files\Git\usr\bin>>"%GITHUB_PATH%"

- name: Cache test binaries
 uses: actions/cache@v3 # if I swtich in that place to actions/[email protected] my workflows are fine 
 id: downloadCache
 with: 
   path: ${{inputs.path}} #so here path and key will be the same like above
   key: ${{inputs.key}}

[lvpx]

Hi @GC-Configit, I see you are using this step as a workaround.

- if: ${{ runner.os == 'Windows' }} # Workaround required when using cache action across operating systems. See https://github.com/actions/cache/issues/591
 name: Use GNU tar not BSD tar
 shell: cmd
 run: |
   echo "Adding GNU tar to PATH"
   echo C:\Program Files\Git\usr\bin>>"%GITHUB_PATH%"

It should not be required as the cache action should work as it is on both environments. If you could try to run your workflow after removing this step?

[GC-Configit]

@pdotl I've tried with out that workaround and it still failing for windows and for ubuntu its fine. Just output is like it not hitting cache key but that's odd because the same cache key is used in ubuntu and there is working fine

Prepare all required actions
Getting action download info
Download action repository 'actions/cache@v3' (SHA:f4278025ab0f432ce369118909e46deec636f50c)
Run ./.github/actions/download-cache
  with:
    path: test-binaries/sub-domain-name
    key: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156-sub-domain-name
    cacheHitCheck: true
  env:
    CACHE_KEY: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156
Run actions/cache@v3
  with:
    path: test-binaries/sub-domain-name
    key: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156-sub-domain-name
  env:
    CACHE_KEY: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156
Cache not found for input keys: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156-sub-domain-name

[pgrivachev]

I have the same issue. The only difference I create cache on windows-latest and restore it on macos-latest. It stopped working today. Removing workaround didn't help.

[GC-Configit]

@pgrivachev I just downgraded the version, just try to change from the actions/cache@v3 to actions/[email protected] (previous release) for last release 3.0.6 the cache is just not working :/

[mladedav]

I've also encountered the issue.

I created cache on ubuntu and it is available for ubuntu and macOS but not Windows. I've created a matrix for my cache creation job and now the two caches seem to be distinct while having the same cache keys.

So whatever changed it seems to only affect windows runners.

I've also just noticed that I've been using actions/cache@v2 so I'm not sure if the issue isn't on the caching mechanism of the runners themselves.

[GC-Configit]

@mladedav just try to add this workaround for windows before you are using actions/cache@v2 , it should be probably working:

- if: ${{ runner.os == 'Windows' }} # Workaround required when using cache action across operating systems. See https://github.com/actions/cache/issues/591
 name: Use GNU tar not BSD tar
 shell: cmd
 run: |
   echo "Adding GNU tar to PATH"
   echo C:\Program Files\Git\usr\bin>>"%GITHUB_PATH%"

[lvpx]

@GC-Configit @mladedav, so without using the workaround(using gnu tar instead of bsd tar in windows), the expected behaviour is caching on windows can cause a different cache save even with same key due to difference in compression algorithm used. Please see here in README. So you were correct that the above workaround is required to reuse the same cache across windows.

However, it is clear that the workaround is now broken in the latest release. Please use the previous version v3.0.5 incase this is causing an issue in your workflow while we are looking into resolving this issue.

[lvpx]

@GC-Configit @mladedav we have patched the latest version of actions/cache to work again with the above workaround. Please test with the latest version using actions/cache@v3 to see if it works for you.

[GC-Configit]

On my workflows the problem was solved, thanks @pdotl