-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cache fallback with rolling timed expiration #702
base: main
Are you sure you want to change the base?
Conversation
a3e058a
to
d2c83d8
Compare
Will rebase |
d2c83d8
to
cbe3ec3
Compare
Similar to what is added in actions/setup-node#702, prevents the npm cache from growing indefinitely while still providing a general fallback
@voxpelli thanks for opening this! I think you'll need to run |
@nwalters512 Did so now, waiting for workflow runs to be approved again :) |
@dmitry-shibanov any chance you could take a look at this PR? The introduction of fallback restore keys matches documented best practices and should allow the cache to be used in many more scenarios. |
This has conflicts after #744 was merged, I'm on it |
6ef1113
to
f01118b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
of
Anything I can do to help out on getting this reviewed? |
This PR builds on #323 by @mmorel-35 but with two changes:
cache-invalidate-after-days
option that defaults to 120 days and which sets a rollable prefix between 0 and 9 to all of the cache keys, making it so that a cache key will change after 120 days. Can be set to0
to deactivate. Reason for this is that npm will not remove data by itself: the cache will grow as new packages are installed.This fixes #328 without creating an ever expanding cache size.
This also helps the cache be much more useful with a Dependabot / Renovatebot setup as a project that is dominated by PR:s from such sources will with the current cache setup in actions/setup-node pretty much only get cache misses and thus only ever set caches, rarely ever use them.
This adds a simple mechanism of falling back to a recent cache while avoiding the ever growing cache problem.
Feedback wanted: