From cb001af8a39a02d063d4cba5f1151b292c4d022c Mon Sep 17 00:00:00 2001 From: Bassem Dghaidi <568794+Link-@users.noreply.github.com> Date: Tue, 3 Dec 2024 02:52:39 -0800 Subject: [PATCH] Update README to include deprecation notice --- packages/cache/README.md | 8 ++++++-- packages/cache/RELEASES.md | 4 ++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/packages/cache/README.md b/packages/cache/README.md index 55185032..2f7be8df 100644 --- a/packages/cache/README.md +++ b/packages/cache/README.md @@ -6,6 +6,12 @@ See ["Caching dependencies to speed up workflows"](https://docs.github.com/en/ac 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. This release integrates with the new cache service (v2) APIs. The new service will gradually rollout following the deprecation period. The legacy service will be sunset on **February 1st, 2025**. +- Changes in the `4.0.0` release are **fully backward compatible**. Upgrading to version `4.0.0` should not break or require any changes to your workflows beyond updating your `package.json` to this version. +- **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.** + ## 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](https://github.com/actions/cache). @@ -47,5 +53,3 @@ const cacheKey = await cache.restoreCache(paths, key, restoreKeys) 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](https://docs.github.com/en/actions/learn-github-actions/environment-variables) named `SEGMENT_DOWNLOAD_TIMEOUT_MINS` with timeout value in minutes. - - diff --git a/packages/cache/RELEASES.md b/packages/cache/RELEASES.md index ebe6f031..02be2ac0 100644 --- a/packages/cache/RELEASES.md +++ b/packages/cache/RELEASES.md @@ -5,8 +5,8 @@ #### Important changes - The cache backend service has been rewritten from the ground up for improved performance and reliability. This release integrates with the new cache service (v2) APIs. The new service will gradually rollout following the deprecation period. The legacy service will be sunset on **February 1st, 2025**. -- Changes in this release are **fully backward compatible**. Upgrading to this version should not break or require any changes to your workflows beyond updating your `package.json` to this version. -- **All previous versions of this package will be deprecated**. We recommend upgrading to this version as soon as possible before **February 1st, 2025.** +- Changes in this release are **fully backward compatible**. Upgrading to version `4.0.0` should not break or require any changes to your workflows beyond updating your `package.json` to this version. +- **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.** #### Minor changes