Skip to content
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

Bazel's NO_PROXY doesn't work while setting HTTP_PROXY or HTTPS_PROXY #6400

Closed
weixiao-huang opened this Issue Oct 16, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@weixiao-huang
Copy link

weixiao-huang commented Oct 16, 2018

Description of the problem / feature request:

I want to use bazel to build a go project using rules_go, I have some external packages in my WORKSPACE file. Some of these packages are in github, golang.org, gopkg.in etc., which can be fetched from internet. The other packages are placed in internal network. However, because I'm in China, for fetching the external internet packages from github, golang.org, gopkg.in, I must set a HTTP_PROXY and HTTPS_PROXY for enjoying a high speed. But for fetching the packages in internal network, I must set NO_PROXY.

However, if I set the HTTP_PROXY, HTTPS_PROXY and NO_PROXY and execute bazel build //..., the external packages can be fetched but the internal packages cannot be fetched. Seems bazel doesn't respect NO_PROXY. I use htop and find that bazel will hang in

/cache/dfb1ce1d07f3a35961571a3241719bc6/external/bazel_gazelle_go_repository_tools/bin/fetch_repo --dest /cache/dfb1ce1d07f3a35961571a3241719bc6/external/<internal_package_name> --rev 84535ec2d57a694b372ec5effa446098b2c2202f --importpath <internal_package_address>

The interesting thing is that if I execute the command above directly in the terminal, it can be successfully executed and fetch the packages in the relative directory.

And if I unset HTTP_PROXY and HTTPS_PROXY, I can successfully fetch the internal packages by using bazel.

Feature requests: what underlying problem are you trying to solve with this feature?

I notice that while I set HTTP_PROXY, bazel will show a log about

WARNING: detected http_proxy set in env, setting no_proxy for localhost.

I try to find it in the sources and discover that it seems bazel will set NO_PROXY directly to localhost,127.0.0.1,0:0:0:0:0:0:0:1,::1 regardless of the origin value of NO_PROXY while HTTP_PROXY exists. Than I change the code to make it respects the origin value of NO_PROXY and use bazel to build it.

However, using the bazel built by myself, it also not worked for me to respect NO_PROXY. It cannot fetch the internal packages yet. I also try to reference #4307 and #4299, but it seems not a solution for my problem.

What operating system are you running Bazel on?

I use bazel 0.17.2 in ubuntu 18.04 and 16.04, both have the same bug

What's the output of bazel info release?

release 0.17.2

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

I try to change code like this, and use bazel to rebuild bazel

bazel build //src:bazel

but the problem still exists.

Have you found anything relevant by searching the web?

I just find some issues in bazel's git, but it seems that they have few helps for my problem

@weixiao-huang

This comment has been minimized.

Copy link
Author

weixiao-huang commented Oct 18, 2018

It seems that it's the problem of bazel-gazelle, bazel-gazelle doesn't add NO_PROXY into it's fetcher, it only add HTTP_PROXY and HTTPS_PROXY. After add NO_PROXY into bazel-gazelle, it can successfully work.
However, I wonder whether the codes in bazel have some potential problems that bazel will set NO_PROXY directly to localhost,127.0.0.1,0:0:0:0:0:0:0:1,::1 regardless of the origin value of NO_PROXY while HTTP_PROXY exists. So I try to open a pull request: #6399, if it's convenient to you, could you please help me to find the potential bugs in this design?
Thanks

@lpapp-polatis

This comment has been minimized.

Copy link

lpapp-polatis commented Nov 12, 2018

Hi, is there a short term plan to fix this?

@tetromino

This comment has been minimized.

Copy link
Contributor

tetromino commented Feb 1, 2019

The correct fix for this is to use gRPC's grpc.enable_http_proxy channel argument. We should not be munging no_proxy/NO_PROXY env variables at all.

I have a commit ready internally which fixes it, but it's pending on updating the gRPC version bundled with Bazel (issue #2804). Stay tuned!

@tetromino tetromino self-assigned this Feb 1, 2019

@tetromino

This comment has been minimized.

Copy link
Contributor

tetromino commented Feb 7, 2019

PR #7368 is in, so this is now unblocked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.