cache icon indicating copy to clipboard operation
cache copied to clipboard

Support writing to the cache even on a cache hit

Open Lyeeedar opened this issue 5 years ago • 8 comments

I'm currently trying to cache some resource build intermediates, with the source files coming from all over the repository. As I do not know exactly what files may be source files, I am setting the cache key to be the same one each time:

  • name: Restore resource cache uses: actions/cache@v1 with: path: my/resource/caches key: resourceCache-version1

However the cache isn't being updated at the end of the action, because of the cache being hit. Ideally the action would have a parameter like uploadIfCacheChanged: true, which would make the cache check the hash of the cache contents at the start vs the hash of the contents at the end, and upload the new cache if these are different.

I have a workaround, which is to hash the entire project contents for the key each time (which should never exist), and rely on the restore-key to actually fetch the last contents:

  • name: Restore resource cache uses: actions/cache@v1 with: path: my/resource/caches key: resourceCache-${{ hashFiles('**/*') }}" restore-keys: resourceCache-

However this means that I am constantly uploading 'dead' caches to the cache store, filling it up and potentially removing ones that I want to keep. It also uploads even if the cache contents hasn't changed. It'd be much better if it just overwrote the same one each time, and only if it is different.

Lyeeedar avatar Feb 02 '20 17:02 Lyeeedar

when i hacked the "utils.isExactKeyMatch" ,

   if (utils.isExactKeyMatch(primaryKey, state)) {
        core.info(
            `Cache hit occurred on the primary key ${primaryKey}, not saving cache.`
        );
        core.info(
            `But... I want always saving cache (condition is empty)`
        );
        //return;
    }

    core.debug("Reserving Cache");
    const cacheId = await cacheHttpClient.reserveCache(primaryKey);

the [reserveCache] api throw error [warning]Cache already exists. Scope: refs/heads/master, Key: test-Linux-43307440, Version: (null)

maybe we need one destory api , or support vesion update

biner avatar Feb 22 '20 03:02 biner

I have a similar request - sometimes I end-up with an empty cache if build fails and cache is not populated and there's no way to fix that unless I make changes to the hashed file, which is Pipfile.lock in my case.

inikolaev avatar Mar 11 '20 13:03 inikolaev

When using ccache for C or C++ code we would need the same feature as the cache always needs to be updated.

christhalinger avatar Mar 20 '20 17:03 christhalinger

Is this a duplicate of #109?

christhalinger avatar Mar 20 '20 18:03 christhalinger

This is very similar to #109 or at least the conclusion of it: People want to update some caches. Either always or when the contents changed. See https://github.com/actions/cache/issues/109#issuecomment-625768169 pointing to #135 which allows to compute a key AFTER the build which can be used for that.

But IMO simpler solution would be that the cache action checks if the cache content has changed and updates it if required. Not updating it is confusing and unexpected for people not fully familiar

Flamefire avatar Sep 05 '20 18:09 Flamefire

This issue is stale because it has been open for 365 days with no activity. Leave a comment to avoid closing this issue in 5 days.

github-actions[bot] avatar Dec 30 '21 08:12 github-actions[bot]

ephemient avatar Dec 30 '21 08:12 ephemient

I do see why we might really want to update a cache, even when tracked files were not modified.

I do think that including year-month as part of the key could alleviate the problem as it would force keys to reset every 30 days. Or you can implement a similar formula to prevent them from being outdated for too long.

ssbarnea avatar Jun 28 '22 10:06 ssbarnea

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

github-actions[bot] avatar May 29 '23 08:05 github-actions[bot]

This issue was closed because it has been inactive for 5 days since being marked as stale.

github-actions[bot] avatar Jun 04 '23 08:06 github-actions[bot]