Closed ludwigbacklund closed 5 years ago
I guess the best thing we can do is programmatically defend against this by including a timeout, but you'll still get a lock file failure in the end. For some reason npm is hanging here and not returning.
but you'll still get a lock file failure in the end
Hmm, why is that? If it has failed once, will it always fail again (even if it's not going to time out with the request this time)? I just want it to try again. Also is there a way to debug what npm is doing when it gets stuck?
Based on your log, npm is running but not returning. Or maybe it's still running and just needs more time? I'm not sure it's caused by the rebase part itself.
Questions:
Hmm okay so I now saw that Renovate actually renamed the PR 15 minutes after I ran it (I had gone away for a meeting at that point and my ssh timed out so I couldn't see). I tried it again with a different PR that had the same problem and it actually does finish at some point, giving me the same ETIMEDOUT error that is presented in the PR. So it seems if I can figure out why it keeps timing out then this will resolve itself automatically. I'm not sure if there's anything you could but if you wanted maybe you could force a lower timeout value somehow? 15 minutes is a bit excessive I think, but maybe there's a reason for it being so high in npm.
If you copy the package.json
and package-lock.json
into a new folder (no node_modules) and then update one of the packages in package.json
manually before running npm install
, how long does it take?
@rarkins I found out what the problem was with the timeouts. We use a corporate proxy here and require every outgoing request to go through it. npm takes the HTTP_PROXY and HTTPS_PROXY environment variables into account for this but those get discarded here: https://github.com/renovatebot/renovate/blob/master/lib/manager/npm/post-update/index.js#L353. If I just let it use process.env
there then it doesn't lock up and doesn't get any timeouts.
Digging some more I find an exposeEnv
config key:
https://github.com/renovatebot/renovate/blob/master/lib/config/migration.js#L112
(that is not documented on the site?) that sets this global.trustLevel
to high if set to true, so setting that to true and reverting my previous change also makes it work. Not sure what the deal is with this key but it makes it play nice with our corporate proxy so I'll be using it. Insights into this are appreciated though.
@ludwigbacklund exposeEnv
is the old term, which is why you see it in the migration file. You should directly configure trustLevel="high"
in your bot config. Documentation here: https://renovatebot.com/docs/self-hosted-configuration/#trustlevel
Basically there are some risks to exposing all env to child processes that a repository user can influence, which is why it's opt-in.
Ah, that makes sense. Thanks!
Thanks for keeping me updated about what the root cause was
What Renovate type are you using? Renovate CLI
Describe the bug Renovate CLI gets stuck trying to run npm install in a PR that has been renamed to include "rebase!" in the title. That PR had previously failed with a "lock file problem, ETIMEDOUT" (which is another problem, but for another time). I wanted to try again so I put "rebase!" in the title and ran the CLI again which resulted in this.
Did you see anything helpful in debug logs? Nothing that looks like an apparent error.
To Reproduce
Expected behavior Rebasing and updating the package*.json files without getting stuck.
Screenshots None
Additional context Org/repo has been censored with *