Cache: Support writing to the cache even on a cache hit

Created on 2 Feb 2020  Â·  5Comments  Â·  Source: actions/cache

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.

enhancement

Most helpful comment

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

All 5 comments

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

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.

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

Is this a duplicate of #109?

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dhadka picture dhadka  Â·  5Comments

dcecile picture dcecile  Â·  6Comments

Fatme picture Fatme  Â·  3Comments

Cerberus picture Cerberus  Â·  5Comments

sergeyzwezdin picture sergeyzwezdin  Â·  5Comments