Feature request: Option to force save when cache is found

[youroff]

Currently the existing cache record is not updated on cache hit, which breaks our workflow where cache key is formed out of branch name. Yet with incremental package resolution and compilation which our platform facilitates just fine it would make perfect sense and speed up the pipeline significantly. Can we have an option to allow force rewrite?

I'm aware of current "workaround" to include run_id into cache key, but with that approach we had our cache overflowing in just one day. This is what we observed yesterday: Approaching total cache storage limit (17 GB of 10 GB Used)

The proposal is to have an option, something like overwrite: true and use it here: https://github.com/actions/cache/blob/main/src/saveImpl.ts#L44

Is there anything that I miss? If that sounds reasonable, I can prepare a PR.

[deemp]

You can purge old cache like in this action https://github.com/MyAlbum/purge-cache.

There's a PR implementing this action in TypeScript https://github.com/MyAlbum/purge-cache/pull/2

[youroff]

@deemp can you elaborate on usage please? My understanding is that resolved cacheKey is passed through state provider, and if it matches primary key on save, then saving is skipped. So if I purge the cache using API at some point between restore and save, it won't trigger save anyways. Or was it about making some caches (marked with run_id) live shorter?

[deemp]

@youroff, you can add your custom purge logic to actions/cache.

actions/cache has 2 phases.

• The initial phase runs when the workflow comes to the actions/cache step.
• The Post phase runs when the workflow finishes and it's time to save a cache.

https://github.com/MyAlbum/purge-cache demonstrates how to collect the information about caches and remove them. You can copy code from there into a fork of actions/cache and run purge at any phase.

For example, you can use core.restoreCache with { lookupOnly = true } in the post phase to check if a cache is present. If it is, you can purge it at that moment and save a new cache. Moreover, you can purge N least recently created caches.

I did something similar here https://github.com/nix-community/cache-nix-action/blob/e610e3b4a09520142fddecdc3ac921e7173cb48b/src/saveImpl.ts#L50. I knew there will be an error restoring the cache so I checked in the Post phase if a cache was present. If it was true, I skipped saving a cache.

Due to an issue https://github.com/actions/toolkit/pull/1378#issuecomment-1478388929, I had to use a slightly modified call to core.restoreCache. https://github.com/nix-community/cache-nix-action/blob/e610e3b4a09520142fddecdc3ac921e7173cb48b/src/utils/actionUtils.ts#L91

Overall, you have these tools and probably some more, so you can devise a strategy and then decide on caches naming.

[youroff]

Is there anything that would prevent overwrite if I end up forking actions/cache and forcing save on cache-hit? Would the backend reject such write? But either way, thank you for pointers, I'll look into these examples!

[deemp]

https://github.com/MyAlbum/purge-cache was able to purge caches in my fork. https://github.com/nix-community/cache-nix-action was able to save caches (and it's a fork of actions/cache). From this evidence, I conclude that if you use the functionality used by actions/cache and purge-cache, your fork will work OK.

It may be better to consult https://docs.github.com/en/actions/creating-actions/creating-a-javascript-action as I don't really know much about GitHub Actions

UPD: you should set permissions: actions: write

[github-actions[bot]]

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]]

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