Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,6 @@ See ["Caching dependencies to speed up workflows"](https://docs.github.com/en/ac
### v4

* Updated to node 20
* Added a `save-always` flag to save the cache even if a prior step fails

### v3

Expand Down
8 changes: 6 additions & 2 deletions action.yml
Original file line number Diff line number Diff line change
Expand Up @@ -29,15 +29,19 @@ inputs:
save-always:
description: 'Run the post step to save the cache even if another step before fails'
default: 'false'
required: false
required: false
deprecationMessage: |
save-always does not work as intended and will be removed in a future release.
A separate `actions/cache/restore` step should be used instead.
See https://github.com/actions/cache/tree/main/save#always-save-cache for more details.
outputs:
cache-hit:
description: 'A boolean value to indicate an exact match was found for the primary key'
runs:
using: 'node20'
main: 'dist/restore/index.js'
post: 'dist/save/index.js'
post-if: "success() || github.event.inputs.save-always"
post-if: "success()"
branding:
icon: 'archive'
color: 'gray-dark'
19 changes: 1 addition & 18 deletions caching-strategies.md
Original file line number Diff line number Diff line change
Expand Up @@ -243,24 +243,7 @@ with:

### Saving cache even if the build fails

There can be cases where a cache should be saved even if the build job fails. For example, a job can fail due to flaky tests but the caches can still be re-used. You can use `actions/cache/save` action to save the cache by using `if: always()` condition.

Similarly, `actions/cache/save` action can be conditionally used based on the output of the previous steps. This way you get more control on when to save the cache.

```yaml
steps:
- uses: actions/checkout@v4
.
. // restore if need be
.
- name: Build
run: /build.sh
- uses: actions/cache/save@v4
if: always() // or any other condition to invoke the save action
with:
path: path/to/dependencies
key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}
```
See [Always save cache](./save/README.md#always-save-cache).

### Saving cache once and reusing in multiple workflows

Expand Down
52 changes: 39 additions & 13 deletions save/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,19 +70,45 @@ with:

### Always save cache

There are instances where some flaky test cases would fail the entire workflow and users would get frustrated because the builds would run for hours and the cache couldn't be saved as the workflow failed in between. For such use-cases, users now have the ability to use the `actions/cache/save` action to save the cache by using an `if: always()` condition. This way the cache will always be saved if generated, or a warning will be generated that nothing is found on the cache path. Users can also use the `if` condition to only execute the `actions/cache/save` action depending on the output of previous steps. This way they get more control of when to save the cache.
There are instances where some flaky test cases would fail the entire workflow and users would get frustrated because the builds would run for hours and the cache couldn't be saved as the workflow failed in between.
For such use-cases, users now have the ability to use the `actions/cache/save` action to save the cache by using an [`always()`](https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/expressions#always) condition.
This way the cache will always be saved if generated, or a warning will be generated that nothing is found on the cache path. Users can also use the `if` condition to only execute the `actions/cache/save` action depending on the output of previous steps. This way they get more control of when to save the cache.

To avoid saving a cache that already exists, the `cache-hit` output from a restore step should be checked.

The `cache-primary-key` output from the restore step should also be used to ensure
the cache key does not change during the build if it's calculated based on file contents.

```yaml
steps:
- uses: actions/checkout@v4
.
. // restore if need be
.
- name: Build
run: /build.sh
- uses: actions/cache/save@v4
if: always() // or any other condition to invoke the save action
with:
path: path/to/dependencies
key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}
name: Always Caching Primes

on: push

jobs:
build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v4

- name: Restore cached Primes
id: cache-primes-restore
uses: actions/cache/restore@v4
with:
key: ${{ runner.os }}-primes
path: |
path/to/dependencies
some/other/dependencies

# Intermediate workflow steps

- name: Always Save Primes
id: cache-primes-save
if: always() && steps.cache-primes-restore.outputs.cache-hit != 'true'
uses: actions/cache/save@v4
with:
key: ${{ steps.cache-primes-restore.outputs.cache-primary-key }}
path: |
path/to/dependencies
some/other/dependencies
```