Bazel: Bypassing Proxy Restriction in Bazel

[rainfld]

I got the problem while building certain projects with bazel behind the proxy.

Looks like this proxy restriction has been discussed in several threads such as #587 .

Is there any standard way I can bypass this restriction behind the proxy?

My system setup:
Ubuntu 14.04.5 LTS \n \l
4.2.0-27-generic

My bazel info:

Build label: 0.13.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Oct 18 21:33:40 +50297 (1525078013620)
Build timestamp: 1525078013620
Build timestamp as int: 1525078013620

An example of the error message I got:

Such as following:

.../cloud_workspace/gVisor_work/gvisor$ bazel build runsc
WARNING: ignoring http_proxy in environment.

ERROR: ...BUILD:5:1: no such package '@com_github_google_subcommands//': failed to fetch com_github_google_subcommands: # cd .; git clone https://github.com/google/subcommands .../.cache/bazel/_bazel_xxx/edc13988a9a72723b729e37bbbf7469b/external/com_github_google_subcommands
Cloning into '.../.cache/bazel/_bazel_xxx/edc13988a9a72723b729e37bbbf7469b/external/com_github_google_subcommands'...
fatal: unable to access 'https://github.com/google/subcommands/': Failed to connect to github.com port 443: Connection timed out
2018/05/10 03:34:18 exit status 128
and referenced by '//runsc:runsc'
ERROR: Analysis of target '//runsc:runsc' failed; build aborted: no such package '@com_github_google_subcommands//': failed to fetch com_github_google_subcommands: # cd .; git clone https://github.com/google/subcommands .../.cache/bazel/_bazel_xxx/edc13988a9a72723b729e37bbbf7469b/external/com_github_google_subcommands
Cloning into '.../.cache/bazel/_bazel_xxx/edc13988a9a72723b729e37bbbf7469b/external/com_github_google_subcommands'...
fatal: unable to access 'https://github.com/google/subcommands/': Failed to connect to github.com port 443: Connection timed out
2018/05/10 03:34:18 exit status 128
INFO: Elapsed time: 215.585s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (10 packages loaded)

[ijpulidos]

Yeah, it's just dumb for bazel not to respect proxy system settings, +1 for this. Btw, the error I'm getting is the following

WARNING: ignoring http_proxy in environment.
WARNING: Output base '/home/user/.cache/bazel/_bazel_user/c755bec3dd0b887b7f18ba2cfd196d1f' is on NFS. This may lead to surprising failures and undetermined behavior.
WARNING: Config value opt is not defined in any .rc file
ERROR: error loading package '': Encountered error while reading extension file 'closure/defs.bzl': no such package '@io_bazel_rules_closure//closure': Error downloading [https://mirror.bazel.build/github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz, https://github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz] to /home/user/.cache/bazel/_bazel_user/c755bec3dd0b887b7f18ba2cfd196d1f/external/io_bazel_rules_closure/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz: All mirrors are down: [Unable to tunnel through proxy. Proxy returns "HTTP/1.1 407 Proxy Authentication Required"]
ERROR: error loading package '': Encountered error while reading extension file 'closure/defs.bzl': no such package '@io_bazel_rules_closure//closure': Error downloading [https://mirror.bazel.build/github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz, https://github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz] to /home/user/.cache/bazel/_bazel_user/c755bec3dd0b887b7f18ba2cfd196d1f/external/io_bazel_rules_closure/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz: All mirrors are down: [Unable to tunnel through proxy. Proxy returns "HTTP/1.1 407 Proxy Authentication Required"]
INFO: Elapsed time: 15.041s
INFO: 0 processes.

Any ideas on how to work around this or make bazel respect my settings is appreciated.

[aehlig]

I'm a bit confused about what you are actually expecting. As you've seen, we're moving to the Skylark rules for external repositories, which call the version control system (in your case git) directly. So the global git configuration is honoured; also the environment is passed on. To phrase my question differently: if you had to clone the repository outside bazel, how would you do that, and how does that differ from what the Skylark git rules do?

[b-ak]

This worked for me. I was building tensorflow.

username@hostname:~$ unset http_proxy 
username@hostname:~$ unset https_proxy 
username@hostname:~$ export HTTPS_PROXY=http://me:[email protected]:8000
username@hostname:~$ export HTTPS_PROXY=http://me:[email protected]:8000

[tolot27]

I have configured both the lower and upper case variant http[s]_proxy and still get:

ERROR: error loading package '': Encountered error while reading extension file 'closure/defs.bzl': no such package '@io_bazel_rules_closure//closure': Error downloading [https://mirror.bazel.build/github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz, https://github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz] to /home/fmg/.cache/bazel/_bazel_fmg/d032a9c4976bff0bb0f430cbb5e25039/external/io_bazel_rules_closure/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz: All mirrors are down: [Unable to tunnel through proxy. Proxy returns "HTTP/1.1 407 authenticationrequired"]
Building: no action

Unsetting the lower case https_proxy does not help either. curl, wget and git clone work.
It looks to me that bazel does not pass the credentials to the proxy, hence the error 407.

[tolot27]

Even providing the credentials directly to the JVM like with bazel --host_jvm_args=-Dhttps.proxyUser=<username> --host_jvm_args=-Dhttps.proxyPassword=<password> build ... does not work.

In ProxyHelper.java I do not see any obvious error. Is this class used for downloading?

[aehlig]

@tolot27 Again, my recommendation was to try using the Skylark versions of the respective rules. I.e., try adding load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository", "new_git_repository") at the beginning of your WORKSPACE file and set the environment as you would when calling git directly.

(If you call the native git_repository rule indirectly, e.g., through another repository, you will have to patch that indirect call as well.)

[aehlig]

Closing, as the native git_repository rules does not exist any more anyway.