Upload files to "/"
This commit is contained in:
+40
-23
@@ -12,7 +12,7 @@ This document lists some of the strategies (and example workflows if possible) w
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
- uses: actions/cache@v5
|
||||
- uses: actions/cache@v3
|
||||
with:
|
||||
key: ${{ some-metadata }}-cache
|
||||
```
|
||||
@@ -24,7 +24,7 @@ In your workflows, you can use different strategies to name your key depending o
|
||||
One of the most common use case is to use hash for lockfile as key. This way, same cache will be restored for a lockfile until there's a change in dependencies listed in lockfile.
|
||||
|
||||
```yaml
|
||||
- uses: actions/cache@v5
|
||||
- uses: actions/cache@v3
|
||||
with:
|
||||
path: |
|
||||
path/to/dependencies
|
||||
@@ -37,7 +37,7 @@ One of the most common use case is to use hash for lockfile as key. This way, sa
|
||||
If cache is not found matching the primary key, restore keys can be used to download the closest matching cache that was recently created. This ensures that the build/install step will need to additionally fetch just a handful of newer dependencies, and hence saving build time.
|
||||
|
||||
```yaml
|
||||
- uses: actions/cache@v5
|
||||
- uses: actions/cache@v3
|
||||
with:
|
||||
path: |
|
||||
path/to/dependencies
|
||||
@@ -54,7 +54,7 @@ The restore keys can be provided as a complete name, or a prefix, read more [her
|
||||
In case of workflows with matrix running for multiple Operating Systems, the caches can be stored separately for each of them. This can be used in combination with hashfiles in case multiple caches are being generated per OS.
|
||||
|
||||
```yaml
|
||||
- uses: actions/cache@v5
|
||||
- uses: actions/cache@v3
|
||||
with:
|
||||
path: |
|
||||
path/to/dependencies
|
||||
@@ -73,7 +73,7 @@ Caches scoped to the particular workflow run id or run attempt can be stored and
|
||||
On similar lines, commit sha can be used to create a very specialized and short lived cache.
|
||||
|
||||
```yaml
|
||||
- uses: actions/cache@v5
|
||||
- uses: actions/cache@v3
|
||||
with:
|
||||
path: |
|
||||
path/to/dependencies
|
||||
@@ -81,12 +81,12 @@ On similar lines, commit sha can be used to create a very specialized and short
|
||||
key: cache-${{ github.sha }}
|
||||
```
|
||||
|
||||
### Using multiple factors while forming a key depending on the need
|
||||
### Using multiple factors while forming a key depening on the need
|
||||
|
||||
Cache key can be formed by combination of more than one metadata, evaluated info.
|
||||
|
||||
```yaml
|
||||
- uses: actions/cache@v5
|
||||
- uses: actions/cache@v3
|
||||
with:
|
||||
path: |
|
||||
path/to/dependencies
|
||||
@@ -102,7 +102,7 @@ The [GitHub Context](https://docs.github.com/en/actions/learn-github-actions/con
|
||||
|
||||
While setting paths for caching dependencies it is important to give correct path depending on the hosted runner you are using or whether the action is running in a container job. Assigning different `path` for save and restore will result in cache miss.
|
||||
|
||||
Below are GitHub hosted runner specific paths one should take care of when writing a workflow which saves/restores caches across OS.
|
||||
Below are GiHub hosted runner specific paths one should take care of when writing a workflow which saves/restores caches across OS.
|
||||
|
||||
#### Ubuntu Paths
|
||||
|
||||
@@ -146,9 +146,9 @@ In case you are using a centralized job to create and save your cache that can b
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v6
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- uses: actions/cache/restore@v5
|
||||
- uses: actions/cache/restore@v3
|
||||
id: cache
|
||||
with:
|
||||
path: path/to/dependencies
|
||||
@@ -171,9 +171,9 @@ You can use the output of this action to exit the workflow on cache miss. This w
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v6
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- uses: actions/cache/restore@v5
|
||||
- uses: actions/cache/restore@v3
|
||||
id: cache
|
||||
with:
|
||||
path: path/to/dependencies
|
||||
@@ -194,7 +194,7 @@ steps:
|
||||
If you want to avoid re-computing the cache key again in `save` action, the outputs from `restore` action can be used as input to the `save` action.
|
||||
|
||||
```yaml
|
||||
- uses: actions/cache/restore@v5
|
||||
- uses: actions/cache/restore@v3
|
||||
id: restore-cache
|
||||
with:
|
||||
path: |
|
||||
@@ -204,7 +204,7 @@ If you want to avoid re-computing the cache key again in `save` action, the outp
|
||||
.
|
||||
.
|
||||
.
|
||||
- uses: actions/cache/save@v5
|
||||
- uses: actions/cache/save@v3
|
||||
with:
|
||||
path: |
|
||||
path/to/dependencies
|
||||
@@ -219,7 +219,7 @@ On the other hand, the key can also be explicitly re-computed while executing th
|
||||
Let's say we have a restore step that computes key at runtime
|
||||
|
||||
```yaml
|
||||
uses: actions/cache/restore@v5
|
||||
uses: actions/cache/restore@v3
|
||||
id: restore-cache
|
||||
with:
|
||||
key: cache-${{ hashFiles('**/lockfiles') }}
|
||||
@@ -228,7 +228,7 @@ with:
|
||||
Case 1: Where an user would want to reuse the key as it is
|
||||
|
||||
```yaml
|
||||
uses: actions/cache/save@v5
|
||||
uses: actions/cache/save@v3
|
||||
with:
|
||||
key: ${{ steps.restore-cache.outputs.cache-primary-key }}
|
||||
```
|
||||
@@ -236,14 +236,31 @@ with:
|
||||
Case 2: Where the user would want to re-evaluate the key
|
||||
|
||||
```yaml
|
||||
uses: actions/cache/save@v5
|
||||
uses: actions/cache/save@v3
|
||||
with:
|
||||
key: npm-cache-${{hashfiles(package-lock.json)}}
|
||||
```
|
||||
|
||||
### Saving cache even if the build fails
|
||||
|
||||
See [Always save cache](./save/README.md#always-save-cache).
|
||||
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@v3
|
||||
.
|
||||
. // restore if need be
|
||||
.
|
||||
- name: Build
|
||||
run: /build.sh
|
||||
- uses: actions/cache/save@v3
|
||||
if: always() // or any other condition to invoke the save action
|
||||
with:
|
||||
path: path/to/dependencies
|
||||
key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}
|
||||
```
|
||||
|
||||
### Saving cache once and reusing in multiple workflows
|
||||
|
||||
@@ -253,12 +270,12 @@ In case of multi-module projects, where the built artifact of one project needs
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v6
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- name: Build
|
||||
run: ./build-parent-module.sh
|
||||
|
||||
- uses: actions/cache/save@v5
|
||||
- uses: actions/cache/save@v3
|
||||
id: cache
|
||||
with:
|
||||
path: path/to/dependencies
|
||||
@@ -269,9 +286,9 @@ steps:
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v6
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- uses: actions/cache/restore@v5
|
||||
- uses: actions/cache/restore@v3
|
||||
id: cache
|
||||
with:
|
||||
path: path/to/dependencies
|
||||
@@ -280,7 +297,7 @@ steps:
|
||||
- name: Install Dependencies
|
||||
if: steps.cache.outputs.cache-hit != 'true'
|
||||
run: ./install.sh
|
||||
|
||||
|
||||
- name: Build
|
||||
run: ./build-child-module.sh
|
||||
|
||||
|
||||
Reference in New Issue
Block a user