actions/cache
1
0
Fork 0
mirror of https://code.forgejo.org/actions/cache.git synced 2024-11-30 23:59:16 +01:00
Code Activity

Merge pull request #896 from actions/bishal-pdMSFT-patch-1

Browse source 
Add readme section for good practices
This commit is contained in:
Bishal Prasad 2022-08-23 16:33:03 +05:30 committed by GitHub
commit 5f975d03e6
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
README.md
View file

@ -229,6 +229,25 @@ A cache gets downloaded in multiple segments of fixed sizes (`1GB` for a `32-bit
Default value of this timeout is 60 minutes and can be customized by specifying an [environment variable](https://docs.github.com/en/actions/learn-github-actions/environment-variables) named `SEGMENT_DOWNLOAD_TIMEOUT_MINS` with timeout value in minutes.
## Known practices and workarounds
Following are some of the known practices/workarounds which community has used to fulfill specific requirements. You may choose to use them if suits your use case. Note these are not necessarily the only or the recommended solution.
#### Update a cache
A cache today is immutable and cannot be updated. But some use cases require the cache to be saved even though there was a "hit" during restore. To do so, use a `key` which is unique for every run and use `restore-keys` to restore the nearest cache. For example:
```
- name: update cache on every commit
uses: actions/cache@v3
with:
path: prime-numbers
key: primes-${{ runner.os }}-${{ github.run_id }} # Can use time based key as well
restore-keys: |
primes-${{ runner.os }}
```
Please note that this will create a new cache on every run and hence will consume the cache [quota](#cache-limits).
#### Use cache across feature branches
Reusing cache across feature branches is not allowed today to provide cache [isolation](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache). However if both feature branches are from the default branch, a good way to achieve this is to ensure that the default branch has a cache. This cache will then be consumable by both feature branches.
## Contributing
We would love for you to contribute to `actions/cache`, pull requests are welcome! Please see the [CONTRIBUTING.md](CONTRIBUTING.md) for more information.