actions / actions/setup-node

Incorrect architecture definition for cache key

Open
#1,397 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature request
Dominant language
TypeScript
Stars
5k
Forks
1.7k
Avg merge
3d 12h
Merged PRs (30d)
2

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with src/cache-restore.ts at line 25 and trace how the cache architecture is selected for setup-node. Reproduce with the two macos-latest workflows in the issue, then verify that x64 and arm64 builds use separate caches based on the requested architecture rather than the host architecture.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, typescript
Domain
ci-cd, devops
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.