Cache: Failed to extract the cache, but taken as a successful cache hit anyway

Created on 14 Nov 2019  路  7Comments  路  Source: actions/cache

First the cache was successfully restored here: https://github.com/stevencpp/cpp_modules/commit/bce1c922e0525b936336c67d6ae50e9aed114963/checks?check_suite_id=310043429#step:8:1
Then in the very next commit it failed to restore the cache from the same key to the same path: https://github.com/stevencpp/cpp_modules/commit/23a1cb1b99b080800c3d8f122085a2d5a2a5116a/checks?check_suite_id=311040306#step:8:1 .
There were no changes between the two commits that could explain the change, so maybe there were some changes to the action at that time ?
A few commits later it still failed to restore the cache but now all the checks were successful and yet it refused to save the cache, thinking that it was a cache hit
https://github.com/stevencpp/cpp_modules/commit/664390b2b1665f8a413fe3546db0fda3ea909390/checks?check_suite_id=311386473#step:27:1
So, it would be helpful to figure out what caused the extraction to fail in the first place, but in any case such failures should either fail the cache action or at least allow rebuilding and saving the cache afterwards.

bug

Most helpful comment

v1 has been updated with this fix, thanks for finding this!

All 7 comments

Hey @stevencpp, we haven't released a new version of the action for ~9 days (https://github.com/actions/cache/releases)

I'm not sure what's going on as we should be correctly creating the /usr/local/share/vcpkg/installed directory before extracting the tar. (See https://github.com/actions/cache/blob/master/src/restore.ts#L89)

Is this a consistent failure?

Could you try enabling step debug logging? (https://help.github.com/en/actions/automating-your-workflow-with-github-actions/managing-a-workflow-run#enabling-step-debug-logging)

The cache-hit output should correctly be set to false, as it indicates if the cache failed to restore. As caches are immutable, save will fail if the key already exists so it's correct to not save a new cache.

Yes it happens on every run. Here's the step debug output for the failed tar command https://github.com/stevencpp/cpp_modules/commit/93d0bbafce2b9208f314a04e4b08b3574403f9b1/checks?check_suite_id=311849601#step:8:61 .

By the way, the link in that article to https://help.github.com/en/articles/virtual-environments-for-github-actions#creating-and-using-secrets-encrypted-variables is outdated. That page has been moved to https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets .

I added some code to the step immediately after the extraction to check whether the directory exists and it does. https://github.com/stevencpp/cpp_modules/runs/304845356#step:9:99 Is there any possibility that the effect of that mkdirP call is delayed until after the tar command ?

@stevencpp Great catch! Didn't realize mkdirP was an async function, and we do need to await it. Fixing at #100

Going to wait until Monday to bump the release v1 tag once we've tested everything in that release. I've updated the release branch which you can use in your workflow to test out the fix.

- uses: actions/cache@releases/v1

"Cache restored from key: Linux-vcpkg" .. seems to be working now. Thanks !

v1 has been updated with this fix, thanks for finding this!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mands picture mands  路  5Comments

binhxn picture binhxn  路  3Comments

sergeyzwezdin picture sergeyzwezdin  路  5Comments

Fatme picture Fatme  路  3Comments

FacetGraph picture FacetGraph  路  3Comments