Closed calvinbui closed 3 years ago
If I add a key option, would that be suitable for you? For example, something like this:
steps:
- plugins:
- gencer/cache#master:
id: ruby
backend: s3
key: "v1-cache-{{ id }}-{{ runner.os }}-{{ checksum 'Gemfile.lock' }}"
restore-keys:
- 'v1-cache-{{ id }}-{{ runner.os }}-'
- 'v1-cache-{{ id }}-'
compress: true
fail: false # or continue_on_failure: true # <-- here we go
# other options below...
I'm actually not sure at the moment what option name should we give here. fail
, allow_failure
or continue_on_failure
(Buildkite compatible). Any ideas?
continue_on_error
sounds nice.
Agreed. 👍
Hey @calvinbui! Can you try below:
steps:
- plugins:
- gencer/cache#fix-33: # <- PR branch here
id: ruby
backend: s3
key: "v1-cache-{{ id }}-{{ runner.os }}-{{ checksum 'Gemfile.lock' }}"
restore-keys:
- 'v1-cache-{{ id }}-{{ runner.os }}-'
- 'v1-cache-{{ id }}-'
compress: true
continue_on_error: true # <- Hope it will work for you :)
# other options below...
Let me know the result so I can merge the PR.
Working 👍
Released as v2.4.9
🎉
The plugin skips caching if the exit status is not 0 (https://github.com/gencer/cache-buildkite-plugin/blob/v2.4.8/hooks/post-command#L28)
We have steps in our pipeline that may exit with a non-zero code but would still like to cache anyway like when linting fails. The linting cache is still useful for the next run.