You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using a self-hosted runner and using this action to setup-node and install yarn.
I know on github-hosted runners, yarn is already pre-installed but it would be good if yarn was installed by this action for those of us using self-hosted.
Running setup-node with the following workflow and it works
A later step in the workflow then attempts to run yarn:
Run yarn install --ignore-scripts --frozen-lockfile
/actions-runner/_work/_temp/58e53b82-f9ae-4c68-9cec-75f75831208b.sh: line 1: yarn: command not found
##[error]Process completed with exit code 127.
This of course works on github hosted runners just fine, but since I just migrated to an EC2 instance that doesn't have yarn installed, I am now having issues.
While this works, I find it rather hacky. It would be good for this action to not need to rely on github's instances to have yarn package installed.
EDIT:
I wanted to add the documentation acts as if yarn is a given, since it has sections on usage with yarn Publish to npmjs and GPR with yarn:. Perhaps some clarification in that section that if you're on self-hosted runners you will need to install yarn yourself via npm install -g yarn and uninstall it at the end of your job with npm uninstall -g yarn
Reacted by Mike Fogel, Sebastian Barrenechea, Sergei Shishov, Sam Hamilton, Nils Bonfils, Lucas Dittrich, Jonathan Hefner, David Chwalisz, Jackie Li, Max Ustinov and 35 more
Reacted by Ivan Peshev, Sebastian Barrenechea, Ilya Lukyanovich, Costa Alexoglou, Lucas Medeiros, larabuli, Gabriel Martinez, Zach Gollwitzer, Philipp Trulson, Piyush Chauhan and 2 more
GitHub Runners creates a file called .path in the same directory where you have config.sh. It contains the content of $PATH variable, which is further used during the execution of your workflows.
You have to add a directory with the yarn binary. In my case:
/home/github/.yarn/bin`
Reacted by Adriano de Azevedo, Ganapathy S, Maxime Lebastard, Ryan Khalil, George Evstigneev, Adri Blanco, Leonardo E. Dominguez, MohamedRaslan, Soo Philip Jason Kim, Albirr Karim and 6 more
Reacted by Nghĩa
Reacted by Ali Afghah, Brendan Kamp, Meir Gabay, Leonardo E. Dominguez, Ivan Gaydamakin, Son, Le Cong and treastrain / Tanaka Ryoga
@konsalex Since self-hosted runners are shared and are not a clean instance per job execution, like a github hosted runner would be, the job should do its best to clean itself up after a run so that each future workflow run is running on what amounts to a fresh instance.
If you install software during the run, such as yarn, redis, or terraform without uninstalling it, could potentially cause conflicts with other jobs running as the state of the instance moves further away from the original state.
Say then you try to upgrade versions of something in your workflow but since the old version is still installed from a previous run it may use that and create a difficult to debug situation.
As others have mentioned you can pre-install any software on a self-hosted runner so the workflow itself does not have to be responsible for installing anything, which would side-step this altogether.
Up to you, of course, how you best want to manage that 😃
Note that if you use with: cache: yarn this action will fail if you don't have yarn pre-installed... But since you need node to install yarn.. you can't get out of this without running this action twice or using other actions.
Reacted by Chris Kilding, Eduardo Suarez, Igor Matuszewski, Allan Lewis, Reinaldo Díaz Lugo, Ryan Sullivan, Steve Haslam, Lucas Combs, Zach Gollwitzer, Amy Ryan Manny and 51 more
Reacted by Tim gong, Omar Greggio, Filip Vidak and Bohdan Tverdyi
Reacted by lxp, Salvatore Mazzarino, Willem Mouwen, Thomas Eckestad, Mario Jerkovic and Cleviane Rebeca Silva
To +1 on Davide's comment, the lack of yarn install support is a significant obstacle to those of us on self-hosted runners.
The only way to break the chicken-or-egg with: cache: yarn problem, and make caching work on self-hosted runners, is to preinstall yarn on the runner base image (like GitHub does for its own runners). This is not good because then yarn is being managed both by setup-node, and out-of-band by the preinstall step.
NOTE: This way, if you run the yarn uninstall in the step, the Post process will not be able to find yarn and the job will fail.
Actions log shows that the cache was successful, but I am not sure if it is really cached in this case.
Cache Size: ~118 MB (124177777 B)
Cache saved successfully
Cache saved with the key: foo-bar-baz
When I connected to the runner instance that ran the job and ran the yarn command, I got not found, so everything seems to be working. However, this is not an essential solution and I also hope that yarn will be installed with it.
Reacted by Gauravjeet, Allan Lewis, Amy Ryan Manny, Tozzi, Sivli Embir, smein, Jan C. Brammer, Quang Vu Van, Victor Hugo Teles Costa, Oleksandr Dykyi and 11 more
Reacted by uto, Timoteo Frascaroli and Mattèo Gauthier
Reacted by Ivan, Odin Hørthe-Omdal Urdland, bnowak-rototip and Gustavo Contreiras
Reacted by Steve Haslam, mohammed khaled, Andrew Munro, Ivan Leschinsky, Ibrahim Benzer, Eduardo Spada, bruddy-lively, Michal, Brooks Swinnerton, Andrés Morelos and 8 more
Reacted by div, bnowak-rototip, Guilherme M Pim and Ibrahim Khalid
I think the point of contention here is that we need to return the runner back clean. It's easy enough to install the binaries, but given the hassle of making sure they're purged every time, I'd prefer to see them included under Node's control
Reacted by Chris Kilding, NGorco, VaidyaAkhil-Groww, Charlie Day, David Hoepelman, jclark123123, meleu-cw and Jack Ward
GitHub Runners creates a file called .path in the same directory where you have config.sh. It contains the content of $PATH variable, which is further used during the execution of your workflows.
You have to add a directory with the yarn binary. In my case:
Let me get this straight, the solution is for the consumers to:
download an orphaned yarn bin
append the bin location to $GITHUB_PATH
which will prove an agony if you hoped to at least keep that shit out of the workflow
run actions/setup-node
so that we can then exec $ yarn
That's quite an amusing procedure, I admit.
So, what about those who are not using or have migrated from the legacy obsolete, unmaintained, unsupported, ancient yarn 1.* (that luckily doesn't provide proper binaries for the last release, but rather the aforementioned orphaned bin we use as a workthefaroundabout) and have pretty much no choice but to use corepack - the official tool for managing node package managers - to install yarn?
Are we gonna have to exploit quantum state to both install it and not install it for this shit to work, or we adding support for something that node took ownership of? It is not a separate concern anymore.
tldr.
Anyways, done with the rant, debugging self-hosted runners combined with this, well, definitely doesn't qualify as fun.
I'll put up a PR proposal for fixing this later/tomorrow, depending on how much of yarn installation control I end up having to expose.
Prior to this yaml on node 20 use corepack use yarn@* to write e.. "packageManager": "yarn@4.0.2+sha256.825003a0f561ad09a3b1ac4a3b3ea6207af2796d54f62a9420520915721f5186", to package.json which is read by corepack install (it's not this on node 18.)
...
steps:
- name: Checkout Repouses: actions/checkout@v4
- name: Setup Node.js environmentuses: actions/setup-node@v4with:
node-version: 20
- run: | corepack enable && corepack install # use the in-repo yarn version
- name: Setup Yarn in Nodeuses: actions/setup-node@v4with:
cache: "yarn"# uses the system node, which was updated prior.
...
Reacted by romainh1, Stanislau Kviatkouski and O`brian
vitest:
runs-on: ubuntu-lateststeps:
- uses: actions/checkout@v4
- name: Set up Nodeuses: actions/setup-node@v3with:
node-version: 20cache: 'yarn'# FIXME: Because the setup-node action is dumb, we have to manually# install the dependencies ourselves. See: https://github.com/actions/setup-node/issues/182
- name: Install dependenciesrun: yarn install
- name: Run testsrun: yarn test:unit:ci
Just putting it out there. For me the problem was the docker engine which was preinstalled with ubuntu 20.4.
I installed yarn globally, the path existed in ENV, I could succesfully execute yarn via cli but I would get the "yarn: command not found" error message whenever the self-hosted runned was executed.
Unistalling the docker engine fixed the issue for me. I do not no the reason for this.
Activity
GoldFlsh commentedon Aug 12, 2020
Workaround is to install yarn yourself using npm (after running this action)
and later can uninstall it -
While this works, I find it rather hacky. It would be good for this action to not need to rely on github's instances to have yarn package installed.
EDIT:
I wanted to add the documentation acts as if
yarnis a given, since it has sections on usage with yarnPublish to npmjs and GPR with yarn:. Perhaps some clarification in that section that if you're on self-hosted runners you will need to install yarn yourself vianpm install -g yarnand uninstall it at the end of your job withnpm uninstall -g yarnpperzyna commentedon Oct 28, 2020
GitHub Runners creates a file called .path in the same directory where you have config.sh. It contains the content of
$PATHvariable, which is further used during the execution of your workflows.You have to add a directory with the yarn binary. In my case:
/home/github/.yarn/bin`vicke4 commentedon Jan 12, 2021
@pperzyna thanks! I spent 30mins guessing why it was not working even after updating the path. Seems
run.shhas to be restarted.konsalex commentedon Jun 23, 2021
Hey @GoldFlsh , why should we uninstall
yarnat the end of a job?GoldFlsh commentedon Jun 24, 2021
@konsalex Since self-hosted runners are shared and are not a clean instance per job execution, like a github hosted runner would be, the job should do its best to clean itself up after a run so that each future workflow run is running on what amounts to a fresh instance.
If you install software during the run, such as yarn, redis, or terraform without uninstalling it, could potentially cause conflicts with other jobs running as the state of the instance moves further away from the original state.
Say then you try to upgrade versions of something in your workflow but since the old version is still installed from a previous run it may use that and create a difficult to debug situation.
As others have mentioned you can pre-install any software on a self-hosted runner so the workflow itself does not have to be responsible for installing anything, which would side-step this altogether.
Up to you, of course, how you best want to manage that 😃
https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#differences-between-github-hosted-and-self-hosted-runners
Install yarn
davide-bertola-deltatre commentedon Nov 4, 2021
Note that if you use
with: cache: yarnthis action will fail if you don't have yarn pre-installed... But since you need node to install yarn.. you can't get out of this without running this action twice or using other actions.chriskilding commentedon Nov 11, 2021
To +1 on Davide's comment, the lack of yarn install support is a significant obstacle to those of us on self-hosted runners.
The only way to break the chicken-or-egg
with: cache: yarnproblem, and make caching work on self-hosted runners, is to preinstall yarn on the runner base image (like GitHub does for its own runners). This is not good because then yarn is being managed both by setup-node, and out-of-band by the preinstall step.mila411 commentedon Nov 12, 2021
Hi everyone. I faced the same problem and this may sound really stupid, but I solved it this way:
(Thanks for the tip, @davide-bertola-deltatre)
NOTE: This way, if you run the yarn uninstall in the step, the Post process will not be able to find yarn and the job will fail.
Actions log shows that the cache was successful, but I am not sure if it is really cached in this case.
Cache Size: ~118 MB (124177777 B) Cache saved successfully Cache saved with the key: foo-bar-bazWhen I connected to the runner instance that ran the job and ran the yarn command, I got not found, so everything seems to be working. However, this is not an essential solution and I also hope that yarn will be installed with it.
jasonk commentedon Nov 24, 2021
FYI: There isn't a chicken-and-egg problem, you don't need Node to install yarn:
mila411 commentedon Nov 27, 2021
I think the point of contention here is that we need to return the runner back clean. It's easy enough to install the binaries, but given the hassle of making sure they're purged every time, I'd prefer to see them included under Node's control
switching from yarn for more check this actions/setup-node#182
switching from yarn for more check this actions/setup-node#182
albirrkarim commentedon Mar 12, 2022
Thanks @pperzyna
Let me share my approach, maybe it will useful.
Find out where is the yarn
First on your server run:
which yarnthen you got the yarn location, like this
copy the path (not including the yarn)
Edit path
run
you got something like
aaaaa:bbbb:ccccseparated with
:then paste the
/home/admin/.nvm/versions/node/v16.14.0/binso the
.pathbecomeaaaaa:bbbb:cccc:/home/admin/.nvm/versions/node/v16.14.0/binDon't add the enter or something. Just give the
:and paste next to itRestart runner
You need restart it. so it will load the new path
Mostly you are running with
svc.shthen stop itRun it again
6 remaining items
CI: have workflow install Yarn if not present
raegen commentedon Dec 27, 2023
Let me get this straight, the solution is for the consumers to:
$GITHUB_PATHactions/setup-node$ yarnThat's quite an amusing procedure, I admit.
So, what about those who are not using or have migrated from the legacy obsolete, unmaintained, unsupported, ancient yarn 1.* (that luckily doesn't provide proper binaries for the last release, but rather the aforementioned orphaned bin we use as a workthefaroundabout) and have pretty much no choice but to use corepack - the official tool for managing node package managers - to install yarn?
Are we gonna have to exploit quantum state to both install it and not install it for this shit to work, or we adding support for something that node took ownership of? It is not a separate concern anymore.
tldr.
Anyways, done with the rant, debugging self-hosted runners combined with this, well, definitely doesn't qualify as fun.
I'll put up a PR proposal for fixing this later/tomorrow, depending on how much of yarn installation control I end up having to expose.
Jackbennett commentedon Jan 11, 2024
Corepack & Yarn is a bad joke.
Prior to this yaml on node 20 use
corepack use yarn@*to write e.."packageManager": "yarn@4.0.2+sha256.825003a0f561ad09a3b1ac4a3b3ea6207af2796d54f62a9420520915721f5186",topackage.jsonwhich is read bycorepack install(it's not this on node 18.)... steps: - name: Checkout Repo uses: actions/checkout@v4 - name: Setup Node.js environment uses: actions/setup-node@v4 with: node-version: 20 - run: | corepack enable && corepack install # use the in-repo yarn version - name: Setup Yarn in Node uses: actions/setup-node@v4 with: cache: "yarn" # uses the system node, which was updated prior. ...joshbuker commentedon Jul 5, 2024
Running into this issue in July 2024...
Current workaround:
Mikaela commentedon Jul 5, 2024
Another workaround is to replace all calls to
yarnwithcorepack yarnwhich has the additional benefit of knowing exactly which version you are using.add act readme, fix makefile yarn call to work as per: actions/setup-…
add act readme, fix makefile yarn call to work as per: actions/setup-…
make local build work when calling 'yarn'. see: actions/setup-node#18…
smartinio commentedon Nov 4, 2024
After upgrading to Node 22,
corepack enablestopped working:Worked around using this (requires
jq)Without jq:
fix(pipeline): cache yarn deps with corepack (#2405)
vaxevanis commentedon Nov 18, 2024
Just putting it out there. For me the problem was the docker engine which was preinstalled with ubuntu 20.4.
I installed yarn globally, the path existed in ENV, I could succesfully execute yarn via cli but I would get the "yarn: command not found" error message whenever the self-hosted runned was executed.
Unistalling the docker engine fixed the issue for me. I do not no the reason for this.
GustavoContreiras commentedon Jun 30, 2025
I had to add to the path too:
DaanSelen commentedon Sep 26, 2025
This still works, we just have to manually bump versions in the URL. Why is this not in the action itself?