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

Support for the NO_PROXY environment variable #563

Open
ianprime0509 opened this issue Nov 23, 2022 · 0 comments · May be fixed by #591
Open

Support for the NO_PROXY environment variable #563

ianprime0509 opened this issue Nov 23, 2022 · 0 comments · May be fixed by #591

Comments

@ianprime0509
Copy link

ianprime0509 commented Nov 23, 2022

Currently, this plugin recognizes the HTTP_PROXY/http_proxy environment variable if no explicit proxy configuration is provided, but ignores the common NO_PROXY/no_proxy environment variables to specify hosts to exclude from proxy use. Unfortunately, this causes issues in some corporate environments where the HTTP_PROXY environment variable is set to enable internet traffic to go through a proxy, but GitHub Enterprise is hosted internally and should be excluded from proxy use via NO_PROXY.

The obvious workaround is to set "proxy": false in the configuration, but it might be useful to respect NO_PROXY when reading the proxy configuration from the HTTP_PROXY environment variable to avoid needing to configure anything manually. The format of NO_PROXY isn't entirely standard, but there are some commonalities among implementations detailed here: https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/

It looks like this was briefly discussed in #356, with some potential code to handle it: #356 (comment) It was argued there that recognizing it would be unnecessary complexity, given only one domain is accessed, but I think it does make sense given the scenario described above, where the necessary environment variables are already set to auto-configure most applications, but this plugin only respects one of them, leading to incorrect results unless manual configuration is used.

ianprime0509 added a commit to ianprime0509/semantic-release-github that referenced this issue Feb 4, 2023
Closes semantic-release#563

BREAKING CHANGE: The `no_proxy` and `NO_PROXY` environment variables are
now respected when obtaining proxy configuration from the environment,
bypassing the proxy when they match the GitHub host. This does not apply
when [`proxy`](https://github.com/semantic-release/github#proxy) is
explicitly provided in the plugin configuration.
@ianprime0509 ianprime0509 linked a pull request Feb 4, 2023 that will close this issue
ianprime0509 added a commit to ianprime0509/semantic-release-github that referenced this issue Feb 4, 2023
Closes semantic-release#563

BREAKING CHANGE: The `no_proxy` and `NO_PROXY` environment variables are
now respected when obtaining proxy configuration from the environment,
bypassing the proxy when they match the GitHub host. This does not apply
when [`proxy`](https://github.com/semantic-release/github#proxy) is
explicitly provided in the plugin configuration.
ianprime0509 added a commit to ianprime0509/semantic-release-github that referenced this issue Feb 4, 2023
Closes semantic-release#563

BREAKING CHANGE: The `no_proxy` and `NO_PROXY` environment variables are
now respected when obtaining proxy configuration from the environment,
bypassing the proxy when they match the GitHub host. This does not apply
when [`proxy`](https://github.com/semantic-release/github#proxy) is
explicitly provided in the plugin configuration.
ianprime0509 added a commit to ianprime0509/semantic-release-github that referenced this issue Feb 4, 2023
Closes semantic-release#563

BREAKING CHANGE: The `no_proxy` and `NO_PROXY` environment variables are
now respected when obtaining proxy configuration from the environment,
bypassing the proxy when they match the GitHub host. This does not apply
when [`proxy`](https://github.com/semantic-release/github#proxy) is
explicitly provided in the plugin configuration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant