actions
Add new setting save-on-success.
Proposal to implement https://github.com/actions/cache/issues/1570, https://github.com/actions/cache/discussions/1598
Description
Allows to control whether new caches can be written in post action on success.
Motivation and Context
In some cases you want to read but not save a new cache. For instance when you run workflows on a tag action, then you probably want to read caches from the main/default branch, but you most likely do not want to create new caches. The current solution is to separate restore and save actions which is cumbersome.
In #1452 the always_save feature was removed.
I propose to add a new config save-on-success that defaults to true and can be set false to prevent cache writing. Now this new value can be set from available context - just like you could when separating the steps - granted the decision must be available upfront. That above described decision is in fact available immediately on job creation. So we can use the new setting to simplify the setup.
How Has This Been Tested?
Local experiments
Screenshots (if appropriate):
Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Documentation (add or update README or docs)
Checklist:
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the CONTRIBUTING document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.
What is the status of this? This could really improve our workflows!
An owner needs to approve the workflows and merge on green :-)
@salmanmkc any chance you could approve, merge & release this? I've tested this on a fork and this is working great!
@salmanmkc any chance you could approve, merge & release this? I've tested this on a fork and this is working great!
@salmanmkc Is there's any chance to merge this?
Hi, this is not my area, I'm not one of the reviewers for cache
Hi @eirnym, thanks for contributing, as this change won't work due to the limitation pointed out by @joshmgross, we won't be accepting it.
Given that this use-case can be addressed with a combination of save/restore actions, I don't see a need for us to introduce new functionality to achieve the same outcome using a new parameter.
Hi, thank you for your comments. Is it correct to say, that the only way is to write a custom action like it's done in Python setup?
@eirnym that might be the best way to accomplish your use-case, if you want to apply complicated logic to your caching, however for precisely what is described above, it sounds like you could accomplish this with
actions/cache/save@v4
and
actions/cache/restore@v4
You can see some examples that may help you here and combine that with simple conditions based on branch name or whatever else you'd like to act on.
In 99% of cases of such customization (on my experience) it's enough to save only on default branch (whatever the name is), and there will be many users if there will be an official generic cache support of this if functionality provided.
This is important to avoid potential cache poisoning from PRs coming outside.