Cache: Split this action into save-cache and restore-cache actions

Created on 4 Nov 2019  路  14Comments  路  Source: actions/cache

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

enhancement

Most helpful comment

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

All 14 comments

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 on post (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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

aleks-ivanov picture aleks-ivanov  路  5Comments

evandrocoan picture evandrocoan  路  3Comments

jcornaz picture jcornaz  路  4Comments

dhadka picture dhadka  路  5Comments

FacetGraph picture FacetGraph  路  3Comments