Pass additional restore-keys to cache action

[gustavovnicius]

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

https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key

setup-java/src/cache.ts

Line 100 in 5b36705

const matchedKey = await cache.restoreCache(packageManager.path, primaryKey);

could be changed to something like:

const restoreKey = `${CACHE_KEY_PREFIX}-${process.env['RUNNER_OS']}-${packageManager.id}`;
const matchedKey = await cache.restoreCache(packageManager.path, primaryKey, [restoreKey]); 

[gustavovnicius]

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-keys makes the performance of setup-java unacceptably 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]

Hello @gustavovnicius
Thanks for your input, i am starting to investigate the problem.

[dsame]

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

The PR #285 should be reverted. It makes caching useless unless the code is exactly the same.

[gustavovnicius]

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]

The PR #285 should be reverted. It makes caching useless unless the code is exactly the same.

The cache must be renewed if any dependency has changed. In the other case the cache keeps obsolete dependencies and grows infinitely.

[dsame]

What I'm proposing on #367 is a solution that works both ways. Having a customisable cache key prefix gives it enough flexibility to be used in many different setups.

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]

The feature request is declined because the requested functionality exist in the other action https://github.com/actions/cache