cache: Configurable save cache on failure
Currently this cache action will only save caches if all tests succeed. In many cases this is desirable behavior. However I have some projects with long build times and flakey test suites. It would be very helpful if I could configure the cache to be saved regardless of the test suite success or failure.
I have created a fork of this project action to set the post-if to always()
.
Is it possible to make the cache policy configurable? Or to pass post-if as an argument from the cache configuration?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 172
- Comments: 40 (6 by maintainers)
Commits related to this issue
- #36 #35 tentative adding gmic-py and gmic-cli compilation cache(8) using https://github.com/actions/cache/issues/92 — committed to myselfhimself/gmic-py by myselfhimself 4 years ago
- #36 #35 tentative adding gmic-py and gmic-cli compilation cache(8) using https://github.com/actions/cache/issues/92 — committed to myselfhimself/gmic-py by myselfhimself 4 years ago
- Persist CI cache on test failure. github.com/actions/cache/issues/92 github.com/ChrisCummins/ProGraML/issues/129 — committed to ChrisCummins/ProGraML by ChrisCummins 4 years ago
- cache htmltest even on fail This is a workaround for actions/cache#92. — committed to kylrth/kylrth.github.io by kylrth 2 years ago
- cache htmltest even on fail This is a workaround for actions/cache#92. — committed to kylrth/kylrth.github.io by kylrth 2 years ago
- cache htmltest even on fail This is a workaround for actions/cache#92. — committed to kylrth/kylrth.github.io by kylrth 2 years ago
- Enhances the original live patching of the `cache` … action by running on `success() || failure()`, to prevent caching on `cancelled()`. This central enhancement, plus better paths, in-lined documen... — committed to Olf0/gh-actions-cache-always by Olf0 a year ago
- Update `main` branch with recent commit set (#1) * Enhances the original live patching of the `cache` … action by running on `success() || failure()`, to prevent caching on `cancelled()`. This ce... — committed to Olf0/gh-actions-cache-always by Olf0 a year ago
- CI: use new granular cache restore/save actions See https://github.com/actions/cache/issues/92#issuecomment-1362456629 — committed to scijava/pom-scijava by ctrueden a year ago
- Switch to actions/cache restore/save actions/cache does not keep the cache upon test failures. See: https://github.com/actions/cache/issues/92 — committed to awelzel/zeek by awelzel a year ago
- Switch to actions/cache restore/save actions/cache does not keep the cache upon test failures. See: https://github.com/actions/cache/issues/92 — committed to awelzel/zeek by awelzel a year ago
Seems like it would make a lot of sense in some circumstances.
Say I have following steps:
It would make sense if post cache could happen conditionally on success of dependencies install, code style step is irrelevant to it.
I made a fork of this repository that gives you full control over when the cache is saved. This allows you to both set your own
if: always()
(or success or failure or what you want) as well as run the save action where/when you want. Docs here: https://github.com/MartijnHols/actions-cacheFor the OP it sounds like you run install and tests in a single job. If you place the save action after the step that generates the things you want to cache, you can achieve this without
always
. For example:If you want your cache to be saved regardless of a previous failure you can change the
if: steps.cache.outputs.cache-hit != 'true'
line intoif: always() && steps.cache.outputs.cache-hit != 'true'
.Next fork with latest upstream changes (including the new 5GB cache limit): https://github.com/marketplace/actions/always-upload-cache
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. 😄
I also desperately need this. For my use cases (grading of student assignments), it is expected that at least some of the tests will fail most of the time, so having a completely successful run is rare. This means caching is basically useless, as the cache will never actually be persisted.
@gerbal I’ve tried your fork, but it also doesn’t seem to work. The post-action simply never runs (it stays a grey square in the log UI), same as with the original cache action.
I made https://github.com/mxxk/gh-actions-cache-always into a reusable action, which patches the original
actions/cache
to change thepost-if: 'success()'
predicate topost-if: 'success() || failure()'
..github/actions/cache-always/action.yml:
Show file contents
You can use it by saving the above action into its recommended location and writing:
instead of
e.g.
Edits: 2022-11-11: run on success() || failure(), to prevent caching on cancelled()
An alternative workaround, which does not require maintaining a forked version of
actions/cache@v3
, is to check out the action repo manually, modifyaction.yml
, and run the modified action from its local path:You can see a minimal example of a full workflow in https://github.com/mxxk/gh-actions-cache-always. The modified
actions/cache@v3
command still saved the cache even though the job https://github.com/mxxk/gh-actions-cache-always/runs/5847143256 failed.(Of course, this is only a hack, since the
sed
command which finds and deletes thepost-if:
line fromaction.yml
is quite janky.)Hey all, 👋🏽
We have created a discussion with a proposal that we feel will solve this problem, do let us know your feedback, thanks 😊
@pat-s, could you please fix deprecation warnings in your fork:
Thanks.
Yeah. If you want, you could use my fork and just change the “success()” to “always()”.
https://github.com/actions/cache/pull/498#issuecomment-753804797
It lets you control the behavior of the post action with an environment variable. So you could “always” run the post action and then have an environment variable that is set to true or false to control whether or not to update the cache. There are likely dozens of solutions similar to mine.
The authors of actions/cache ought to look at what the common forks of this repo are trying to do and incorporate the features.
Any progress on this one? I have the same problem as mentioned in https://github.com/actions/cache/issues/92#issuecomment-562204290.
Would this feature be officially supported?
I’ve just updated my fork to v3.0.1: https://github.com/marketplace/actions/always-upload-cache
FYI: such fork already exists: https://github.com/pat-s/always-upload-cache
For anyone interested, you are welcome to try out my advanced cache action built on top of this repo. Simply specify your cache targets in a config file, and finishes restoration, build, and save as many caches as you want in one step:
https://github.com/ktmud/cached-dependencies#speficy-when-to-restore-and-save
Relevant section: https://github.com/actions/cache/tree/main/save#always-save-cache
We have the same use case @trent-boyd for this: failing / flaky end-to-end tests are really hard to debug due to having to re-run build processes: by allowing to cache builds even on failure would speed up this considerably.
This would be extremely useful for my team. We use Next.js. The process goes something like this.
It would be great to save the Next cache even if the Cypress tests fail. There’s a high likelihood that the Cypress tests fail due to flakiness, but sometimes we just need to update the Cypress tests. That change doesn’t invalidate the build cache, so it would be nice to have that speedier build on the second run.
Hmm, I understood the requirement. Thanks @LorenzoBettini. I’ll take a look at this.
+1
We’re running a test suite with Hypothesis, a property based testing tool. The database should be saved (cached) on failed runs, so failed tests are replayed on subsequent runs.