Repository navigation
Pass additional restore-keys to cache action #366
Description
As can be seen in their examples: https://github.com/actions/cache/blob/main/examples.md#java---gradle
It is recommended that additional restore-keys are passed when using actions/cache. https://github.com/actions/cache#inputs
Line 100 in 5b36705
const restoreKey = `${CACHE_KEY_PREFIX}-${process.env['RUNNER_OS']}-${packageManager.id}`;
const matchedKey = await cache.restoreCache(packageManager.path, primaryKey, [restoreKey]);
Activity
gustavovnicius commentedon Aug 12, 2022
I see that this: #285 was recently merged, but the cost doesn't outweigh the gains.
It is not realistic to bust the cache completely whenever a version changes. Many projects nowadays rely on automated dependency updates, not using
restore-keysmakes the performance ofsetup-javaunacceptably bad in those cases.A better way to handle this would be to expose an input to let people decide how often they want to expire their caches.
dsame commentedon Aug 15, 2022
Hello @gustavovnicius
Thanks for your input, i am starting to investigate the problem.
dsame commentedon Aug 15, 2022
@gustavovnicius the cache should be updated whenever the dependencies changed. It is expected behaviour and actually it is not realistic the update of dependencies happens too often.
Nevertheless for some specific use cases it is natural to use full-featured https://github.com/actions/cache actions instead of its simplified implementation built-in into setup-java action.
paramaggarwal commentedon Aug 19, 2022
The PR #285 should be reverted. It makes caching useless unless the code is exactly the same.
gustavovnicius commentedon Aug 19, 2022
What I'm proposing on #367 is a solution that works both ways.
Having a customizable cache key prefix gives it enough flexibility to be used in many different setups.
dsame commentedon Aug 22, 2022
The cache must be renewed if any dependency has changed. In the other case the cache keeps obsolete dependencies and grows infinitely.
dsame commentedon Aug 22, 2022
Built-in cache is not intended to be flexible, it is intended to work out of box in the most cases. For the specific complex caching that requires flexibility and customisation there's https://github.com/actions/cache action
dsame commentedon Aug 22, 2022
The feature request is declined because the requested functionality exist in the other action https://github.com/actions/cache