Skip to content

slow speed in setup-node step #726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 tasks done
eerison opened this issue Mar 24, 2023 · 11 comments
Closed
2 tasks done

slow speed in setup-node step #726

eerison opened this issue Mar 24, 2023 · 11 comments
Assignees
Labels
bug Something isn't working

Comments

@eerison
Copy link

eerison commented Mar 24, 2023

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 🚀

@eerison eerison added bug Something isn't working needs triage labels Mar 24, 2023
@eerison eerison changed the title intermitent spped to setup noode slow speed in setup-node step Mar 24, 2023
@marko-zivic-93
Copy link
Contributor

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

@awer000
Copy link

awer000 commented Mar 27, 2023

So slow too.

@Santas
Copy link

Santas commented Mar 31, 2023

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
Copy link

Tirke commented Apr 3, 2023

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

@lgaspari
Copy link

lgaspari commented Apr 13, 2023

We have a lot of issues like that image 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
Copy link

millsp commented Apr 19, 2023

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

@dusan-trickovic
Copy link

dusan-trickovic commented Apr 28, 2023

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
Copy link

Santas commented May 10, 2023

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

@dusan-trickovic
Copy link

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 :)

@Santas
Copy link

Santas commented May 10, 2023

Yes, Node v19.

@dusan-trickovic
Copy link

Hello @Santas ! Thank you for your patience. I have discussed the issue with my colleagues and, unfortunately, there isn't much that we can do about it at this time. The reason being that it simply isn't an issue on our end - it can take varying amounts of time to fetch and install a Node version that isn't available out of the box in our node-versions repository. As non-LTS versions aren't, that variable definitely applies there.

I will have to close this issue now, as its solution is out of our reach, but if any other problem arises while using our software, please feel free to file a new issue and we will be happy to take a look at it.

Thank you for your time and cooperation! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

9 participants