setup-node: Node setup fails non-deterministically with Yarn starting on November 17th

As @Mause mentioned, this can be temporarily solved by enabling Corepack before running setup-node.

  jobs:
    test:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
+       - name: Enable Corepack before setting up Node
+         run: corepack enable
        - uses: actions/setup-node@v4
          with:
            node-version: 20
        - run: npm ci
        - run: npm test

As @Mause mentioned, this can be temporarily solved by enabling Corepack before running setup-node.

  jobs:
    test:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
+       - name: Enable Corepack before setting up Node
+         run: corepack enable
        - uses: actions/setup-node@v4
          with:
            node-version: 20
        - run: npm ci
        - run: npm test

This is not ideal, because actions/checkout it designed for carrying out git commands, so you can’t be sure that node is present, or that it has the correct version you are specifying in the next step with Node 16 at least required for corepack. Instead I have managed to workaround this issue by running two steps:

      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: corepack enable
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: yarn
      - run: yarn install --immutable

This will setup Node to version 20, run corepack enable, then setup the cache

I was stuck with the same problem. However, putting the Yarn binary in Git management with the following command helped me:

yarn set version latest --yarn-path

@felladrin Yea, that’s better and actually caches my Yarn deps. Setting SKIP_YARN_COREPACK_CHECK=1 and running corepack enable after setup-node was not caching anything.

How do you enable corepack before installing node, since corepack is part of node?

I believe the action runner image contains a copy of node, as most actions are themselves written in JavaScript (including this one I think?)

Committing the Yarn binary to the repo is a good workaround for now, thanks. However, note that doing this is discouraged in Yarn version 4, as the ecosystem should use corepack going forward. So I would love a solution to this setup-node issue sooner rather than later.

If you don’t want to commit the Yarn version you can set SKIP_YARN_COREPACK_CHECK=1 to skip this check. Then later in steps run corepack enable. don’t do this, setup-node wont cache your deps.

Hello @Zamiell , According to my analysis, it seems that the discrepancy between Yarn versions (1.22.19 vs 1.22.21) in different jobs is causing the issue you’re encountering. As per the release notes for Yarn version 1.22.20, a notice will be displayed when Yarn 1.22 identifies a package.json file in the project that references a non-1.x Yarn release using the packageManager field. In this situation, the Yarn version in runner images was updated from v1.22.19 to v1.22.21 on November 16, which potentially led to the display of this error message afterwards. 
At the present moment, the repository doesn’t provide functionality to compare Yarn versions between the global scope and the one specified in the package.json. This feature could be incorporated for future enhancements to the repository. 
 I am going to proceed with closing it. I appreciate your understanding and patience. Many thanks!

We have investigated this issue and found that the action does not upgrade npm,yarn,pnpm.

If you have investigated the issue, can you explain why the error only happens sometimes, and not other times? Naively, I would expect that to indicate some kind of bug in either this GitHub action or the GitHub runner virtual machine.

Furthermore, Yarn 4 was released on October 22nd, 2023, and this GitHub Actions issue started occurring on November 17th, 2023. Which means that Yarn 4 worked just fine with this action for 26 days. Thus, I find your classification of the race condition described in the OP as a “feature request” rather than an “bug” completely baffling. Can you explain further why it is a “feature request” to request that something that already worked continues to work in the same way?

Hey @Zamiell , as per my previous comment, we will consider this issue as an enhancement in future. Feel free to share your inputs !!!

Hello @Zamiell , just a gentle ping!

Can confirm @kurone-kito solution works as a workaround for this 🎉