Pin cache action version

[saibotk]

Description

This pins the cache action to its commit:
0400d5f644dc74513175e3cd8d07132dd4860809
Which is https://github.com/actions/cache/releases/tag/v4.2.4

Motivation and context

This allows people to enable the strict GitHub setting to only run pinned GitHub Actions. See https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization

How has this been tested?

This did not change anything really, but was tested internally in our workflows.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

PR checklist

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• I have added tests to cover my changes.

[jrfnl]

Ha! I was just about to open a PR for this, but luckily noticed this PR already being open.

Would be great if this could be released as a new 3.x version before updating actions/cache to v5.0.0 which was released today and will need to be released as a new major (as it means a change from Node 20 to Node 24).

@ramsey If it helps, the below is the commit message I'd written to argue the case for making/accepting this change.

Recently there has been more and more focus on securing GH Actions workflows - in part due to some incidents.

The problem with "unpinned" action runners is as follows:

• Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.
  Note that GitHub is currently beta-testing a new "immutable releases" feature (= tags and release artifacts can not be changed anymore once the release is published), but whether that has much effect depends on the ecosystem of the packages using the feature.
  Aside from that, it will likely take years before all projects adopt immutable releases.
• Action runners often don't even point to a tag, but to a branch, making the used action runner a moving target.
  Note: this type of "floating major" for action runners used to be promoted as good practice when the ecosystem was "young". Insights have since changed.

While it is convenient to use "floating majors" of action runners, as this means you only need to update the workflows on a new major release of the action runner, the price is higher risk of malicious code being executed in workflows and this risk is exponential for the use of unpinned action runners in a package which is an action runner itself.

GitHub is now also actively promoting enforcing the use of pinned action runners via a new setting introduced a while back and currently, if that settings is turned on, this action runner will cause workflows to fail due to the unpinned use of the actions/cache action runner.

Dependabot can automatically submit PRs to update pinned action runners as long as the commit-hash pinned runner is followed by a comment listing the released version the commit is pointing to, though to be honest, I'm not entirely sure that works for action.yml files.

So this change may mean that you need to manually update the action.yml file more regularly.

A typical workflow for this can be:

1. Subscribe to watch "releases" for the actions/cache repo.
2. Install Pinact if not yet installed.
3. Whenever a new release has been tagged for actions/cache, review the release and then update the SHA in the action.yml file by running pinact run -u.

Future scope: something I have not got up and running yet, but might be worth experimenting with, is running pinact on a cronjob via GitHub Actions to alert on updates needed to the action.yml file and/or automatically create a PR.

Refs:

• https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions
• https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/

Note: I've not applied this change to the workflows in use by this repo itself as whether or not to do so should be a maintainer decision, what with the extra burden of more frequent Dependabot PRs.

But as the action.yml file is part of the published package, that's a different consideration and causes a security risk for other packages.