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 commands fail when behind a Proxy #14896

Closed
adamawolf opened this issue Feb 24, 2022 · 0 comments
Closed

Bazel commands fail when behind a Proxy #14896

adamawolf opened this issue Feb 24, 2022 · 0 comments
Labels
P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug

Comments

@adamawolf
Copy link
Contributor

adamawolf commented Feb 24, 2022

Description of the problem / feature request:

When running local proxy software such as ProxyMan or Charles Proxy bazel commands fail with errors like:

Proxy address 127.0.0.1:9090 is not a valid URL

Also, once such an error occurs, only a bazel clean -expunge will mend the development environment (even after you disconnect from the Proxy).

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Set up a local proxy, and run any bazel command which requires fetching remote artifacts.

What operating system are you running Bazel on?

macOS Big Sur 11.6.2

What's the output of bazel info release?

release 5.0.0

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

bdcc080
bdcc080

Have you found anything relevant by searching the web?

This response from @kchodorow to a now closed issue #2375 (comment) stating that bazel does not support the "no proxy" environment variable yet, and java treats localhost and 127.* addresses as non-proxied. I don't know what the environment variable she mentioned pertains to (maybe it's supported now?). I'm also unclear if the comment about java treating as non-proxied is relevant. Is the implication that did this not explicitly fail here in the regex parsing, then bazel's downloader would fail further down the line? I'm going to go ahead and create a PR for how I think the regex should be adjusted to permit protocol-less addresses, and then test this in my environment.

adamawolf added a commit to adamawolf/bazel that referenced this issue Feb 24, 2022
@aiuto aiuto added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. untriaged labels Feb 26, 2022
@meteorcloudy meteorcloudy added P2 We'll consider working on this in future. (Assignee optional) type: bug and removed untriaged labels Mar 1, 2022
bazel-io pushed a commit that referenced this issue Mar 2, 2022
Addresses #14896

Closes #14897.

PiperOrigin-RevId: 431949154
brentleyjones pushed a commit to brentleyjones/bazel that referenced this issue Mar 4, 2022
Addresses bazelbuild#14896

Closes bazelbuild#14897.

PiperOrigin-RevId: 431949154
(cherry picked from commit f7d8288)
@Wyverald Wyverald closed this as completed Mar 4, 2022
Wyverald pushed a commit that referenced this issue Mar 4, 2022
Addresses #14896

Closes #14897.

PiperOrigin-RevId: 431949154
(cherry picked from commit f7d8288)

Co-authored-by: Adam Wolf <adam.wolf@robinhood.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug
Projects
None yet
Development

No branches or pull requests

4 participants