optim: add secondary cache key if lock hash doesn't exist#43
Conversation
- follows `restore-keys` example from https://docs.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#example-using-the-cache-action and https://github.com/actions/cache/blame/59a8d125e7227efbef01813bf1ecf30fa8b6bd8c/examples.md#L234 - these specify to use the key with everything but the lock hash in case the specific cache with the lock hash doesn't exist - the thought being that a partial cache is better than no cache
|
@bahmutov any word on this? This PR's been up for about a month now. You didn't add me as a maintainer after #37 (comment), so I can't merge this myself. |
|
@bahmutov following up again |
|
@bahmutov following up a third time... |
|
@bahmutov following up for a fourth time... Nearly 2 months without response now... It seems like this action is unmaintained (issues not responded to for many months) and I'm having to ping several times again even for simple, well-documented PRs. Looks like I'll have to keep a fork then |
|
Question: will it allow https://glebbahmutov.com/blog/do-not-let-npm-cache-snowball/ ? |
|
@bahmutov It depends on when your cache is evicted, but yes it can cause that. NPM's cache is basically designed to grow infinitely with no eviction, but you can run If you believe the official recommendation GitHub has made is faulty, I would suggest filing an issue with |
|
I disagree. I have no idea how often my project will be tested on CI, especially when there are automatic dependency updates. Plus I do not trust the cache clean method to work reliably - and should I run it after every install? Or sometimes? Why increase the complexity when a simple "start from scratch" is enough? |
|
Looks like this was eventually replaced by #73 , which follows a very similar rationale as mine here and adds a periodic clean that I also suggested here to automatically occur within the Action. |
Description
restore-keysexample fromhttps://docs.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#example-using-the-cache-action
and https://github.com/actions/cache/blame/59a8d125e7227efbef01813bf1ecf30fa8b6bd8c/examples.md#L234
case the specific cache with the lock hash doesn't exist
Tags
Doesn't quite resolve, but should make things like #28 happen less. #26 would still be good to solve
Review Notes
Unclear why the primary key is also used duplicatively as a restore key?