cache
cache copied to clipboard
Support writing to the cache even on a cache hit
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.
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
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.
⠀
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.
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.
This issue was closed because it has been inactive for 5 days since being marked as stale.