Time sensitive: upgrade @actions/cache to ^4.0.0

[Link-]

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.

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 the changes in this PR.

Please cut a new release after merging this PR.

More details: actions/toolkit#1890

Tip

I'd highly recommend adding the configuration below to your dependabot.yml to receive further upgrades we will be making to the cache package

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index b18fd29..025b9c1 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -4,3 +4,11 @@ updates:
     directory: '/'
     schedule:
       interval: 'weekly'
+
+  # Enable version updates for npm
+  - package-ecosystem: 'npm'
+    # Look for `package.json` and `lock` files in the `root` directory
+    directory: '/'
+    # Check the npm registry for updates every day (weekdays)
+    schedule:
+      interval: 'weekly'
\ No newline at end of file

---

The tests I ran are positive & everything is working as expected with the new service.

[eregon]

Thank you for the PR!

[MSP-Greg]

@eregon

The source repro for many of the packages in yarn.lock changed from registry.yarnpkg.com to registry.npmjs.org.

Is that desired? Regardless, maybe a yarn upgrade is needed?

[eregon]

Mmh, I just ran the pre-commit so yarn install locally, odd, with yarn 1.22.21.
I guess it's fine. https://stackoverflow.com/questions/69526949/yarn-lock-file-resource-source-changed-from-registry-yarnpkg-com-to-registry-npm
I'd rather avoid touching any other package in this PR to make it easier to assess if anything would break.

@actions/cache@^4.0.0 has many dependencies including things like prettier, but not something we can change here.

[eregon]

@MSP-Greg Thanks for noticing, I fixed that now by restoring the yarn.lock from master and rerunning yarn install.

[eregon]

@Link- Regarding

I'd highly recommend adding the configuration below to your dependabot.yml to receive further upgrades we will be making to the cache package

Is there a way to only create PRs for updates of the actions/cache package?
Because given the huge amount of transitive dependencies I wouldn't want a PR every week to update some package I don't really care about (unproductive busy work).
Just dealing with security issues used to be a pain when we depended on axios, it was terrible, so I got rid of that dependency.
In my experience so far with JS stuff, auto updates break more things than they solve, so they don't seem worth it.
If there is a known bug fix wanted we can always update something specific.

[Link-]

@Link- Regarding

I'd highly recommend adding the configuration below to your dependabot.yml to receive further upgrades we will be making to the cache package

Is there a way to only create PRs for updates of the actions/cache package? Because given the huge amount of transitive dependencies I wouldn't want a PR every week to update some package I don't really care about (unproductive busy work). Just dealing with security issues used to be a pain when we depended on axios, it was terrible, so I got rid of that dependency. In my experience so far with JS stuff, auto updates break more things than they solve, so they don't seem worth it. If there is a known bug fix wanted we can always update something specific.

No problem at all, it's really up to you how you'd like to manage this. It is possible to use: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#allowing-specific-dependencies-to-be-updated