Incorrect architecture definition for cache key

src/cache-restore.ts の 25 行目から始めて、setup-node 用のキャッシュアーキテクチャがどのように選択されるかを追跡します。Issue にある 2 つの macos-latest ワークフローで再現し、その後、x64 と arm64 のビルドがホストアーキテクチャではなく、要求されたアーキテクチャに基づいて別々のキャッシュを使用することを確認します。

Description:
The architecture used to pull the cache is based on the runner's host architecture and not the architecture key supplied to the action. This problem manifests when running two pipelines that use the same host runner but build for different architectures. In this case the action which is building for an architecture that is different from the host will try to pull the cache for it's host architecture which causes the build to fail. The current solution is to only use caching for the pipeline where the host architecture matches the build architecture which is not ideal.

Action version:
Latest

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:

all

Repro steps:
Make two actions pipelines with macos-latest and run with a package.json that include native modules:

for x86_64

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20.17.0'
          cache: 'yarn'
          architecture: 'x64'
      - name: Install dependencies with Yarn
        run: npm_config_arch=x64 yarn install --frozen-lockfile --verbose

for arm64

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20.17.0'
          cache: 'yarn'
      - name: Install dependencies with Yarn
        run: yarn install --frozen-lockfile --verbose

Expected behavior:
These pipelines should have separate caches because they are specifying different architectures even though the host architecture is the same.

Actual behavior:
They pull the same cache key because the key is derived from the runner os architecture instead of the specified architecture in the action.
https://github.com/actions/setup-node/blob/89d709d423dc495668cd762a18dd4a070611be3f/src/cache-restore.ts#L25