-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Installing [email protected] fails continuously for unknown reasons. #838
Comments
Hello, @oliversalzburg! Thank you for reporting the issue, we will take a closer look into it and see what can be done :) |
I'm sure there is nothing really wrong with this specific version, and I've seen other issues that report problems with non-LTS versions. Maybe some good workaround could be suggested for this. Or maybe some troubleshooting mode to at least be able to see the response headers from |
Hello again @oliversalzburg ! Thank you for pointing that out. Based on the version you were trying to install, given that it's a non-LTS one, there's a high chance that this issue isn't on our side to begin with. Those get fetched directly from Have you tried setting it up and running the workflow again since the last time? Were there any changes? Maybe even used self-hosted runners (you can find out more about them in our docs)? They provide some more flexibility in terms of hardware and OS and could, possibly, help you cut down the time it takes for your selected version to be downloaded (you would likely just need to install it locally first). In any case, I will discuss your troubleshooting mode suggestion with the team and see what can be done on that front. For more verbose outputs and information, though, you could also enable debugging on your repo and see if that provides a better insight into the processes happening at the step level. Thank you very much for your cooperation! :) |
@dusan-trickovic I completely accept that this is an upstream issue. I felt like maybe too many GitHub hosted runners try to pull NodeJS versions from their server and they might just try to limit their traffic. I can relate to that. We have since been able to get the pipeline running after many retries. Given that we only needed this version a few times to zero in on an issue, it's no longer blocking us. We're looking into self-hosted runners for other reasons, but I'm sure this would help. I guess, this is a documentation issue at best. I'm not sure if this makes any sense, but could there be a mode of operation where you can drop the |
FWIW, I'm currently also (intermittently) experiencing this issue, |
Same here with
|
Problem continues, github action gets stuck for about 30min. Can at least it has a backoff policy and stop the retrying. This costs 💵 💵 |
Removing deprecated node19 version from CI since it's currently having problems to run on GitHub actions. Refs: actions/setup-node#838
Removing deprecated node19 version from CI since it's currently having problems to run on GitHub actions. Refs: actions/setup-node#838
Removing deprecated node19 version from CI since it's currently having problems to run on GitHub actions. Refs: actions/setup-node#838
See actions/setup-node#838 for more information on the problem with v19.6.0 & non-LTS versions. I also updated to the latest version the actions/checkout, actions/setup-node & actions/cache GitHub Actions.
See actions/setup-node#838 for more information on the problem with v19.6.0 & non-LTS versions. I also updated to the latest version the actions/checkout, actions/setup-node & actions/cache GitHub Actions.
Description:
When I try to install 19.6.0, the pipeline hangs on the
setup-node
step for 25 minutes and then fails.Action version:
v3
Platform:
Runner type:
Tools version:
Node: 19.6.0
Repro steps:
I wish I knew. I hope it's not just the NodeJS version that is causing this.
Expected behavior:
Node is installed.
Actual behavior:
The URL works just fine for me.
The text was updated successfully, but these errors were encountered: