slow speed in setup-node step

[eerison]

Description:
Any idea why some setups are really fast ~5sec and others ~2min ?

Action version:
v3

Platform:

• Ubuntu

Runner type:

• Hosted

Tools version:
npm

Repro steps:
https://github.com/shield-wall/myprofile

Expected behavior:
slow: https://github.com/shield-wall/myprofile/actions/runs/4505022388/jobs/7930236281
fast: https://github.com/shield-wall/myprofile/actions/runs/4505022388/jobs/7930228983

Actual behavior:
every setup be few seconds 🚀

[marko-zivic-93]

Hello @eerison
Thank you for your issue. We will investigate it and come back to you as soon as possible! 🙂

[awer000]

So slow too.

[Santas]

We have the same issue. setup-node should either cache at least some Node v19 binaries or allow caching of the binary through artifacts/... so it doesn't need to be downloaded from nodejs.org on every run.

[Tirke]

We have a lot of issues like that

we added a really low timeout because it can go up to an hour like that doing nothing.

[lgaspari]

We have a lot of issues like that we added a really low timeout because it can go up to an hour like that doing nothing.

Having the same issue here, however in my case it started when I changed from macos-latest runner to self-hosted in my M1. I can't get to pass the setup step due to timeout. It takes up more than an hour to download and it ends up failing anyway because of my job timeout... I've also tried changing node version without luck (from 16.15.x to 16.20.x).

EDIT: It looks like in some cases the setup step works, but the post setup doesn't. Not sure if related, but worth mentioning nonetheless.

[millsp]

Same here, we encounter this frequently https://github.com/prisma/prisma/actions/runs/4746282641/jobs/8429723075#step:9:438

[dusan-trickovic]

Hello, everyone! Thank you for pointing out the inconsistencies in setup times on a project basis. Unfortunately, we believe that the problem here might be a bit tricky...

Given the fact that our hosted toolcache directory and manifest contains only LTS versions (e.g. 16.x, 18.x, 20.x), the action tries and fails to resolve the provided 19.x version by looking into there first. Next, it looks for it in dist (nodejs.org), which does have it, but ultimately can take a varying amount of time that is beyond our control to fetch and set up.

As for the case that @millsp pointed out, where it's version 18 making an issue, we do believe that the problem was also external (and temporary) in nature. That being said, the cache servers might have been temporarily unavailable or a bit overwhelmed with requests which resulted in cache download getting stuck even though the node was installed. Sadly, this was probably more of an infrastructure issue than something we could fix with code...

If you want to learn more about versions (and aliases) in particular, you can check out the README of our repository, more specifically supported version syntax .

If you have any other concerns, feel free to reply or open up a new issue. Alternatively, if we answered your question, please feel free to let us know that also. We appreciate your input! :)

[Santas]

It doesn't make sense the binary isn't at least cached at the job level. Our jobs are again crashing today.

[dusan-trickovic]

Hi, @Santas ! Thank you for the follow-up. We will take a closer look into the issue and, hopefully, come back to you with a potential solution soon. But first, just to clarify - are you still trying to use Node v19 in your jobs? We appreciate your time and cooperation :)