Environment variable "no_proxy" seems to be unsupported

[oolesen]

I've been trying to play around with self hosted runners.

I'm sitting behind a corporate firewall using Github Enterprise, which is also inside the firewall.

I'm using iterativeai/cml:0-dvc2-base1-gpu docker container on a Linux Ubuntu 18.04 machine.
I am fairly confident, my container is set up properly with certificates and proxy settings. For instance can I clone my Github Enterprise repo with no problems. I am also able without any problems to connect an original github runner to my Enterprise repo.

However when I use cml runner, I seem to fail in both of two options:
a) I pass my proxy settings to the docker container, which makes it impossible to reach my Github Enterprise repository (because the proxy is not able to resolve the address).
b) I leave out the proxy settings, so the CML runner can find the Github Enterprise but when it next tries to load the latest Github runner version from github.com, it fails because it doesn't get past the proxy.

It seems to me, that the problem origins in the usage of node-fetch.js, which in turn also only supports either using http/s_proxy or not. But there is no gate evaluating the requested URL and changing the path either through the proxy or not. I'm really no expert in this as you might have guessed after the first few words. So let me try to phrase it in my simple words:

Can you implement cml runner to "respect" the no_proxy setting? Or help me in any other way?

[DavidGOrtega]

👋

cml-runner currently supports http_proxy and https_proxy however we do not support no_proxy yet.
Have you tried to setup https_proxy using the cml-runner?

[oolesen]

Hi David,

yes, that's what I did. Maybe I was unclear there.

If I set up proxy correctly, cml runner will fail to reach my enterprise github, because it's internal, behind the firewall.
If I don't set up proxy, cml runner will reach the enterprise github, but fail to reach anything outside the firewall.

As far as I understand, the only solution is to respect the "no_proxy" setting, like many other (Linux) applications.

[0x2b3bfa0]

It looks like no_proxy could be the best solution for this use case. 🤔

[0x2b3bfa0]

@oolesen, it should be fixed as soon as we review and merge #765

[oolesen]

That’s really good news! Thanks a lot! Can’t wait to try it out!