1
0
Fork 0
toolkit/packages/cache
Josh Gross 01f21badd5
Remove more unused cache APIs
2024-12-17 14:51:57 -05:00
..
__tests__ Tune upload options 2024-12-02 07:32:33 -08:00
src Remove more unused cache APIs 2024-12-17 14:51:57 -05:00
LICENSE.md Add License.md to all npm packages (#548) 2020-08-25 16:26:50 -04:00
README.md Add announcement link 2024-12-04 08:23:10 -08:00
RELEASES.md Add announcement link 2024-12-04 08:23:10 -08:00
package-lock.json Prepare @actions/cache 4.0.0 release 2024-12-03 02:40:00 -08:00
package.json Prepare @actions/cache 4.0.0 release 2024-12-03 02:40:00 -08:00
tsconfig.json Audit Fix (#1480) 2023-08-03 16:36:11 -04:00

README.md

@actions/cache

Functions necessary for caching dependencies and build outputs to improve workflow execution time.

See "Caching dependencies to speed up workflows" for how caching works.

Note that GitHub will remove any cache entries that have not been accessed in over 7 days. There is no limit on the number of caches you can store, but the total size of all caches in a repository is limited to 10 GB. If you exceed this limit, GitHub will save your cache but will begin evicting caches until the total size is less than 10 GB.

⚠️ Important changes

The cache backend service has been rewritten from the ground up for improved performance and reliability. The @actions/cache package now integrates with the new cache service (v2) APIs.

The new service will gradually roll out as of February 1st, 2025. The legacy service will also be sunset on the same date. Changes in this release are fully backward compatible.

All previous versions of this package will be deprecated. We recommend upgrading to version 4.0.0 as soon as possible before February 1st, 2025.

If you do not upgrade, all workflow runs using any of the deprecated @actions/cache packages will fail.

Upgrading to the recommended version should not break or require any changes to your workflows beyond updating your package.json to version 4.0.0.

Read more about the change & access the migration guide: reference to the announcement.

Usage

This package is used by the v2+ versions of our first party cache action. You can find an example implementation in the cache repo here.

Save Cache

Saves a cache containing the files in paths using the key provided. The files would be compressed using zstandard compression algorithm if zstd is installed, otherwise gzip is used. Function returns the cache id if the cache was saved succesfully and throws an error if cache upload fails.

const cache = require('@actions/cache');
const paths = [
    'node_modules',
    'packages/*/node_modules/'
]
const key = 'npm-foobar-d5ea0750'
const cacheId = await cache.saveCache(paths, key)

Restore Cache

Restores a cache based on key and restoreKeys to the paths provided. Function returns the cache key for cache hit and returns undefined if cache not found.

const cache = require('@actions/cache');
const paths = [
    'node_modules',
    'packages/*/node_modules/'
]
const key = 'npm-foobar-d5ea0750'
const restoreKeys = [
    'npm-foobar-',
    'npm-'
]
const cacheKey = await cache.restoreCache(paths, key, restoreKeys)
Cache segment restore timeout

A cache gets downloaded in multiple segments of fixed sizes (now 128MB to fail-fast, previously 1GB for a 32-bit runner and 2GB for a 64-bit runner were used). Sometimes, a segment download gets stuck which causes the workflow job to be stuck forever and fail. Version v3.0.4 of cache package introduces a segment download timeout. The segment download timeout will allow the segment download to get aborted and hence allow the job to proceed with a cache miss.

Default value of this timeout is 10 minutes (starting v3.2.1 and higher, previously 60 minutes in versions between v.3.0.4 and v3.2.0, both included) and can be customized by specifying an environment variable named SEGMENT_DOWNLOAD_TIMEOUT_MINS with timeout value in minutes.