cache
cache copied to clipboard
Split this action into save-cache and restore-cache actions
Proposal: Split this action into two, similar to actions/upload-artifact
/ actions/download-artifact
(also similar to what CircleCI does):
- actions/save-cache
- actions/restore-cache
Rationale: This will give the user a lot more control (e.g. I might want to save the cache even before running the test steps).
Why not add argument instead?
- uses: actions/cache
with:
mode: load
# ...
- uses: actions/cache
with:
mode: save
Not sure what that accomplishes. Also, AFAICT the official actions all start with verbs, because they're, well, actions.
If you fork this repo, you have just one upstream. If you're writing complex pull request, you do it in one place. If you find bug which requires both loading and saving in specific order to reproduce, you report it in one place instead of guessing which one fits best or writing in both. If you want to use older version for any reason, you set one sha instead of two. And if you want to move to newer, but still not-so-fresh version, you just update that sha instead of tracking which changes in repository A will work with repository B.
That's what we have now, with one repo.
I like the idea of controlling when exactly cache should be loaded/saved. But splitting repo for this is overkill. If that's what's needed to have more control (no idea honestly - not an actions writer yet, i stick to workflows for now), split load and save into two actions in separate folders which sounds like best of two worlds to me.
- uses: actions/cache/load
# ...
- uses: actions/cache/save
If we were to implement this capability we would probably do it with an input as @wipe2238 suggests. Given the majority of cases don't need to deal with the complexity of two actions we don't want to force that on users and having three actions in the marketplace cache
, save-cache
, restore-cache
would be very confusing.
While not completely aligning with other verb-noun naming of actions I do think this would be the best compromise.
In the end of the day it's just a slightly different syntax. The most important thing is to get the functionality itself, so we can better manage when caches are saved and restored. I'd appreciate an option to fine-tune it as well!
Doesn't keeping them as one action complicate things? As it is now, there's an implicit save-cache
happening on post
(if: success()
). It's best to make this explicit, i.e. requiring separate restore-cache
and save-cache
actions, and deprecate the cache
action.
Given the majority of cases don't need to deal with the complexity of two actions we don't want to force that on users and having three actions in the marketplace cache, save-cache, restore-cache would be very confusing.
What's the actual use-case of this action when there are no separate save and restore steps? This can't be used to cache dependencies, for example, since you'd want to run the action before installing dependencies...but that would then create an empty cache hit for subsequent runs since the dependencies weren't yet installed.
but that would then create an empty cache hit for subsequent runs since the dependencies weren't yet installed.
No:
As it is now, there's an implicit
save-cache
happening onpost
(if: success()
).
https://github.com/actions/cache/blob/4b0709a0d5bb7cd20f2ca9b9eb3dd620875faec9/action.yml#L20-L21
Ah, gotcha, thanks. Having a mechanism for finer grained control (a la circleci) would definitely be nice though :)
I'm not sure I like this idea either. It goes against the discussion in #94.
@mrmckeb Actually, not splitting this action into two will introduce more config options, so splitting into two is better for #94, as the "cache" action will become explicit save-cache
/ restore-cache
actions (and no post
magic with an awkward step name).
Is there any update on this issue? I have a use case for it which would save me good 20 minutes of build time.
This can solve #106 and #135.
For anyone interested, I have an action built on top of action/cache
that allows you to run restore-cache
and save-cache
separately:
https://github.com/ktmud/cached-dependencies#speficy-when-to-restore-and-save
This would definitely help for the use-case where you need to share some files between multiple jobs and you don't wan't to update the cache in some of them. The are also a lot of feature requests regarding the read-only mode and force update the cache. This will answer all these requests.
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.
Dear bot, please keep this open. Once this issue is solved, you will have plenty more cpu hours at your disposal to mark other issues as stale.
This is too important to go stale. Commenting to help avoid staleness.
Hey all, 👋🏽
We have created a discussion with a proposal that we feel will solve this problem, do let us know your feedback, thanks 😊
Hey everyone 👋🏽
Two new actions actions/cache/restore and actions/cache/save are now available with tag v3
to everyone for use. These can now be used to achieve granular control on the restore and save steps in the cache action.
Do try them and give your feedback. We hope these new actions will take care of your use cases. 🙇🏽
Closing this issue now as we believe the new actions will take care of the same, feel free to reopen it if need be. 😄