Repository navigation
v5 fails immediately when using pnpm #1357
Description
Description:
I'm using corepack to install pnpm. Using v5 the action fails immediately, afaict doesn't even make it to the corepack step.
Action version:
v5
Platform:
- Ubuntu
- macOS
- Windows
Runner type:
- Hosted
- Self-hosted
Tools version:
"engines": {
"node": "24.7.0"
},
"packageManager": "pnpm@10.15.1+sha512.34e538c329b5553014ca8e8f4535997f96180a1d0f614339357449935350d924e22f8614682191264ec33d1462ac21561aff97f6bb18065351c162c7e8f6de67"Repro steps:
name: restore
runs:
using: composite
steps:
- name: Install Node.js
#uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5
with:
node-version-file: package.json
- name: Install pnpm
shell: bash
run: |
corepack enable
corepack prepare --activate
- name: Export pnpm store path
shell: bash
run: |
echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
- name: Setup pnpm cache
uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4
with:
path: ${{ env.STORE_PATH }}
key: ${{ runner.os }}-pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}
restore-keys: |
${{ runner.os }}-pnpm-store-
- name: Install dependencies
shell: bash
run: pnpm install --frozen-lockfile
- name: Store prune
shell: bash
run: pnpm store prunePrepare all required actions
Getting action download info
Download action repository 'actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444' (SHA:a0853c24544627f65ddf259abe73b1d18a591444)
Download action repository 'actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809' (SHA:0400d5f644dc74513175e3cd8d07132dd4860809)
Run ./.github/actions/restore
Run actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444
with:
node-version-file: package.json
always-auth: false
check-latest: false
token: ***
package-manager-cache: true
Resolved package.json as 24.7.0
Attempting to download 24.7.0...
(node:1991) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Acquiring 24.7.0 - x64 from https://github.com/actions/node-versions/releases/download/24.7.0-17283839804/node-24.7.0-linux-x64.tar.gz
Extracting ...
/usr/bin/tar xz --strip 1 --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/32676364-91bc-4278-a2bc-700823b9c0d4 -f /home/runner/work/_temp/96a07732-bdfd-4e82-a07c-8a2a6550709e
Adding to the cache ...
Environment details
node: v24.7.0
npm: 11.5.1
yarn: 1.22.22
Error: Unable to locate executable file: pnpm. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
Expected behavior:
Using v4 everything works as expected:
Prepare all required actions
Getting action download info
Download action repository 'actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020' (SHA:49933ea5288caeca8642d1e84afbd3f7d6820020)
Download action repository 'actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809' (SHA:0400d5f644dc74513175e3cd8d07132dd4860809)
Run ./.github/actions/restore
Run actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020
Resolved package.json as 24.7.0
Attempting to download 24.7.0...
Acquiring 24.7.0 - x64 from https://github.com/actions/node-versions/releases/download/24.7.0-17283839804/node-24.7.0-linux-x64.tar.gz
Extracting ...
/usr/bin/tar xz --strip 1 --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/5be513fa-45a1-4cbf-b962-41ec7d0b828f -f /home/runner/work/_temp/1b86ae81-2e8a-4a03-bb71-adb4c43b321f
Adding to the cache ...
Environment details
node: v24.7.0
npm: 11.5.1
yarn: 1.22.22
Run corepack enable
corepack enable
corepack prepare --activate
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
Preparing pnpm@10.15.1+sha512.34e538c329b5553014ca8e8f4535997f96180a1d0f614339357449935350d924e22f8614682191264ec33d1462ac21561aff97f6bb18065351c162c7e8f6de67 for immediate activation...
Run echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
Run actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809
Cache hit for restore-key: Linux-pnpm-store-b7d2050696ee54d49a8aad9d2b825770a2ccafcb302f1fb77ebbe74d6ce0757b
Received 134217728 of 153022715 (87.7%), 120.0 MBs/sec
Received 153022715 of 153022715 (100.0%), 117.9 MBs/sec
Cache Size: ~146 MB (153022715 B)
/usr/bin/tar -xf /home/runner/work/_temp/43de40db-0b79-4b5b-b9a3-f8da86ea6973/cache.tzst -P -C /home/runner/work/website/website --use-compress-program unzstd
Cache restored successfully
Cache restored from key: Linux-pnpm-store-b7d2050696ee54d49a8aad9d2b825770a2ccafcb302f1fb77ebbe74d6ce0757b
Run pnpm install --frozen-lockfile
Lockfile is up to date, resolution step is skipped
Progress: resolved 1, reused 0, downloaded 0, added 0
Packages: +810
...
Actual behavior:
Action fails immediately.
Activity
v-aparnajyothi-y commentedon Sep 4, 2025
Hello @peterhirn, Thank youf or creating this issue and we will look into it :)
Eynorey commentedon Sep 4, 2025
Same issue, this action has never supported Corepack, and it's getting more and more cumbersome to use.
Unless #531 gains some traction, it might finally be time to look for or build an alternative...
It's a chicken-egg problem that has existed since caching support was introduced:
setup-node's cache featureWe have gotten used to solve this via a two-step approach:
Now we need to set
package-manager-cache: falsein the first call so that the action works at all, even though we want to use the cache, which is super awkward.v-priyagupta108 commentedon Sep 5, 2025
Hi! 👋
Thank you for sharing your workflow and describing the issue.
This behavior is expected with actions/setup-node v5. In this release, caching is automatically enabled if your
package.jsonincludes a validpackageManagerfield (such as pnpm, yarn, or npm). This update is aimed at simplifying dependency caching by default.To turn off automatic caching and restore the previous behavior, set
package-manager-cache: falseinsetup-nodestep:For more information on this update and recommended configuration, please refer to:
If you have any other questions or run into any issues, feel free to ask. We're happy to help!
notaphplover commentedon Sep 5, 2025
Hey @priyagupta108
If the behavior is expected, could you please tell us how to use the action with the caching feature enabled when pnpm is set as the package manager? As @Eynorey already explained, there's no way to use the action without setting
package-manager-cache: false. If only you could support setting a custom package manager, then this caching feature would make sense to non npm users.If your answer is: add
package-manager-cache: falseif you're not using npm, then I would suggest to try not to go that way in the future, for it would mean other package managers are becoming second class citizens. Everybody makes mistakes, I hope you keep up the great work 🙂chore: patch setup node action
tagliala commentedon Sep 5, 2025
Hello,
with this approach:
and a committed
pnpm-lock.yaml, I do not have issues with cache,setup-node@v5, andpnpmYou can take a look at a successful run here:
https://github.com/diowa/ruby3-rails7-bootstrap-heroku/actions/runs/17490730192/job/49679724339
Excerpt from logs:
Note about the
pnpm/action-setup: it is an official action from the pnpm team and it is the documented way of implementing pnpm in the GitHub actions pipelineRefs:
notaphplover commentedon Sep 5, 2025
Hey @tagliala,
Amazing. I was not aware you could set pnpm via
pnpm/action-setupwithout setting up node. Thanks!alexaka1 commentedon Sep 5, 2025
Same issue happens for yarn v4.
error This project's package.json defines "packageManager": "yarn@4.9.4". However the current global version of Yarn is 1.22.22.Except that yarn does not have a setup action. Not to mention the official installation method is via Corepack. https://yarnpkg.com/getting-started/install
dominikg commentedon Sep 8, 2025
edit: i missed updating the second job in the workflow,
package-manager-cache: falseworks.sveltejs/vite-plugin-svelte#1213
previous comment stating the opposite
it fails even when
package-manager-cache: falseis set https://github.com/sveltejs/vite-plugin-svelte/pull/1213/filesnote that these workflows don't use pnpms setup action but rather setup-node twice. first time it is used to be able to run
npm i -g pnpm@version. And only the second time around cache is enabled. this used to work fine in v4tagliala commentedon Sep 8, 2025
Hello, as far as I agree that extra actions are not ideal, I would like to clarify and I will also edit my above comment, that
pnpm/action-setupis an official action from the pnpm team and it is the documented way of implementing pnpm in the GitHub actions pipelineRefs:
Julusian commentedon Sep 8, 2025
We are seeing the same issue with yarn4.
Yarn is installed/setup in the recommended way, so having to manually updated the workflows to disable caching is frustrating. Especially when dependabot is happily opening PRs to update this, which will break everything if merged (I have 15 emails already)
24 remaining items
ci: downgrade actions/setup-node to v4
ci: work around actions/setup-node bug
karlhorky commentedon Oct 24, 2025
Yeah, I just came here from the Breaking changes in V6 section in the readme, since it seems unusual that pnpm and Yarn caching was disabled.
What exactly were the "compatibility issues with automatic caching" that you've identified?
For pnpm, does adding the
pnpm/action-setupbeforeactions/setup-nodeas @tagliala suggested in comment 3257892494 resolve these compatibility issues for pnpm?@priyagupta108 Maybe this should be the recommended configuration, so that caching can be enabled by default, at least for pnpm.
It seems that PR #1374 is a regression in the behavior and features of
actions/setup-node- automatic caching being the default for all package managers seems like a good default.If the automatic caching feature was not working as implemented (for example, failing immediately as @peterhirn reported in this issue #1357), then instead of disabling the automatic caching feature, maybe it's better to fix the automatic caching feature? Eg:
pnpm/action-setupas above and maybe something else for Yarn)Also, consider the users who removed the
cacheinput for v5 - if they upgrade to v6, nothing will appear to explicitly break, but their actions will run more slowly because of the lack of caching:cc @priya-kinthali @aparnajyothi-y @HarithaVattikuti as reviewers of PR #1374
v-priyagupta108 commentedon Oct 28, 2025
@karlhorky, Thank you for your input!
Based on feedback, we disabled automatic caching for pnpm and yarn by default in v5+ due to inconsistent and unpredictable cache paths, especially when using Corepack or custom setups. These issues sometimes led to workflow failures, as reported in this thread. Our intention was to prevent unexpected failures and provide a more stable default experience for all users.
We officially recommend using
pnpm/action-setupbeforeactions/setup-nodein your workflow for projects using pnpm, as mentioned in previous responses and highlighted in the workflow example in our documentation for caching. While this approach is reliable for most users, there are still edge cases, particularly with Corepack and custom setups, that can lead to unpredictable cache paths and workflow failures.We understand that disabling automatic caching for these package managers may result in slower builds due to the lack of caching, so we recommend specifying the
cacheinput explicitly in your workflow if you wish to enable caching for pnpm or yarn, as was done previously. This change was released as a major version(v6) to highlight its impact.We are continuing to explore improvements for other package managers and Corepack support, and will work on incorporating better solutions in future updates while ensuring compatibility and maintainability.
karlhorky commentedon Oct 28, 2025
@priyagupta108 Thanks for the answer!
Ok, are the details documented somewhere? It would be great to get the technical details of each type of failure case, so that someone can try to work on it and hopefully get back to "cache in pnpm and Yarn by default again".
v-priyagupta108 commentedon Oct 30, 2025
@karlhorky, Thank you for your interest!
While we don’t have documentation for every possible failure scenario, most reported issues seem to stem from custom setups, especially when using setup-node for Corepack and package manager installation. For additional context, please refer to the discussion in this issue.
We welcome contributions! PRs or proposed solutions are always appreciated, and community input is invaluable in helping us improve.
karlhorky commentedon Oct 30, 2025
@priyagupta108 I'm not looking for exhaustive documentation of every possible failure scenario.
It would just be helpful if you could provide the results of your research, including the technical details - what you wrote above "custom setups" and "using setup-node for Corepack and package manager installation" is vague, not detailed enough to be helpful for anyone wanting to work on it.
Otherwise, the research that you mentioned that your team has done is opaque and cannot be built upon by the community:
joprice commentedon Nov 8, 2025
Moving pnpm installation before node also assumes the system node is compatible:
The double configure pattern above or using
standalone: trueto use a bundled pnpm works around it.I hit this when testing with act locally, which has an node 16 pre-installed, but could happen with backwards and forwards compat of node versions, but more likely if someone uses a mutable image tag like ubuntu-latest.
v-aparnajyothi-y commentedon Nov 10, 2025
Hello @karlhorky, Thanks for bringing this up and for the detailed context. Just to share a bit of background, the current behavior was introduced mainly to avoid some instability we were seeing when cache paths were resolved automatically. In certain environments (especially with Corepack or custom setups), the resolved package manager location wasn’t always consistent, which resulted in cache misses or failures. So, the goal was to land on something reliable for the majority of setups first.
We do realize that this comes with a trade-off , it puts a bit more setup burden on users who expect everything to be auto-detected. It’s not ideal, and we haven’t ruled out revisiting this flow in the future. For now, we wanted to avoid breaking existing workflows while we gather more real-world usage data and explore options that are safer and more predictable.
Thanks again for raising it and really appreciate the input and patience as we iterate.
karlhorky commentedon Nov 10, 2025
@aparnajyothi-y great, thanks for the info. Good to hear that your team will try to get back to autodetection.
Could you provide detailed reproduction steps and maybe a reproduction repo which show exactly how to recreate the multiple types of inconsistent package manager locations?
This would help community understanding of the problem and allow any solution to be tested against them.
Also, it may lead to community help with resolving the problem - not only end users of
actions/setup-nodebut possibly also the pnpm or Corepack teams.fix(actions#1357): Gracefully handle missing pnpm installation during…
fix: Set package-manager-cache in publish.yml
fix(ci): disable setup-node v5 package-manager-cache (undici crash on…
feat(frontend): add /chat page with SSE streaming (s11b) (#14)