actions/cache
1
0
Fork 0
mirror of https://code.forgejo.org/actions/cache.git synced 2025-04-29 23:09:55 +02:00
Code Activity

Add use case to workarounds doc

Browse source
This commit is contained in:
Matt Johnson-Pint 2022-11-18 14:52:23 -08:00
parent fa2f4155aa
commit ebd65873f7
No known key found for this signature in database
GPG key ID: FC13C394A988CF1D
1 changed files with 29 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

30
workarounds.md
View file

@ -35,4 +35,32 @@ To improve cache restore performance, we can re-enable `zstd` as the compression
The `cache` action will use GNU tar instead of bsd tar on Windows. This should work on all Github Hosted runners as it is. For self-hosted runners, please ensure you have GNU tar and `zstd` installed.
The above workaround is also needed if you wish to use cross-os caching since difference of compression algorithms will result in different cache versions for the same cache key. So the above workaround will ensure `zstd` is used for caching on all platforms thus resulting in the same cache version for the same cache key.
The above workaround is also needed if you wish to use cross-os caching since difference of compression algorithms will result in different cache versions for the same cache key. So the above workaround will ensure `zstd` is used for caching on all platforms thus resulting in the same cache version for the same cache key.
#### Re-evaluating the cache key
By default, the string resolved from the `key` parameter for restoring the cache will also be used for saving the cache. In some situations it may be preferred to re-evaluate the `key` parameter when saving, such as when part of the key's name is not available until after the restore has completed. In such cases, you can add the option `reevaluate-key: true`.
For example, consider a a .NET solution that doesn't *normally* use `packages.lock.json` lock files. You may still want to generate a lock file for purposes of determining the cache key only.
```yaml
- name: Cache Packages
uses: actions/cache@v3
with:
path: ~/.nuget/packages
key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
restore-keys: ${{ runner.os }}-nuget-
reevaluate-key: true
- name: Restore Packages
run: dotnet restore --use-lock-file --nologo
- name: Build
run: dotnet build -c Release --no-restore --nologo
```
Assuming a Linux runner and no pre-existing `packages.lock.json` files:
- The first run will attempt to restore a cache named `"Linux-nuget-"`, which won't exist.
- The lock files will be generated by `dotnet restore` due to the `--use-lock-file` option.
- Because `reevaluate-key: true` is set, the cache will be saved using a key based on the hash of the newly-generated lock files, such as `"Linux-nuget-c2c3fe3d365e39a1be194115ccf5477bde7e17ef902f85ef5b6ef3ce1c6a08bc"`.
- The next run will restore the latest cache, due to the `restore-keys` option matching the requested prefix.
- The lock files will be generated again. If they have changed, then so will the cache key and the cache will be updated.