Caching fails with timeouts due to sunset of the v1 API

[timothyjward]

Description:
The v1 caching service has been sunset. Users must upgrade to at least version 4.2.0 to use the new v2 API.

Action version:
Specify the action version: v4.1.0

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:

Repro steps:
A description with steps to reproduce the issue. If you have a public example or repo to share, please provide the link.

Expected behavior:
The setup-node action completes relatively quickly

Actual behavior:
The setup-node action times out after 5 minutes, affecting both setup and teardown.

[gowridurgad]

Hi @timothyjward,
Thank you for creating this issue, we will investigate it and come back to you as soon as we have some feedback.

[mschfh]

This is expected, see actions/cache README:

We are deprecating some versions of this action. We recommend upgrading to version v4 or v3 as soon as possible before February 1st, 2025. (Upgrade instructions below).

If you are using pinned SHAs, please use the SHAs of versions v4.2.0 or v3.4.0

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

#1270 / #1191 bumped @actions/cache to 4.x, so this should be fixed for setup-node v3.9.0 / 4.2.0 and above.

[timothyjward]

If you are using pinned SHAs, please use the SHAs of versions v4.2.0 or v3.4.0

#1270 / #1191 bumped @actions/cache to 4.x, so this should be fixed for setup-node v3.9.0 / 4.2.0 and above.

In #1270 the cache action is set to 4.0.3. It needs to be at least 4.2.0 to pick up the fix.

[mahabaleshwars]

Hi @timothyjward,
Just to clarify: the cache dependency version 4.0.3 you're referring to is the internal package used from the toolkit (for action authors), whereas 4.2.0 refers to the version of the standalone actions/cache Action that's used directly in workflow YAML.
So, these are related but refer to different components and their versioning is managed separately.