Split this action into save-cache and restore-cache actions about cache

[wipe2238]

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

[wipe2238]

Why not add argument instead?

- uses: actions/cache
  with:
   mode: load

# ...

- uses: actions/cache
  with:
   mode: save

[fsimonis]

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.

[merlinnot]

Is there any update on this issue? I have a use case for it which would save me good 20 minutes of build time.

[chrispat]

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.

[merlinnot]

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!

[mzabaluev]

This can solve #106 and #135.

[teohhanhui]

Not sure what that accomplishes. Also, AFAICT the official actions all start with verbs, because they're, well, actions.

[mrmckeb]

I'm not sure I like this idea either. It goes against the discussion in #94.

[teohhanhui]

@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).

[kotewar]

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. 😄

[dpryan79]

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.

[teohhanhui]

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.

[teohhanhui]

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 on post (if: success()).

cache/action.yml

Lines 20 to 21 in 4b0709a

	post: 'dist/save/index.js'
	post-if: 'success()'

[dpryan79]

Ah, gotcha, thanks. Having a mechanism for finer grained control (a la circleci) would definitely be nice though :)

[ktmud]

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

[slavafomin]

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.

[github-actions]

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.

[henrygab]

This is too important to go stale. Commenting to help avoid staleness.

[kotewar]

Hey all, 👋🏽

We have created a discussion with a proposal that we feel will solve this problem, do let us know your feedback, thanks 😊