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

"new Git integration" page does not respect the proxy settings #12874

Closed
Tracked by #12826
mrsimonemms opened this issue Sep 12, 2022 · 3 comments
Closed
Tracked by #12826

"new Git integration" page does not respect the proxy settings #12874

mrsimonemms opened this issue Sep 12, 2022 · 3 comments
Labels
meta: never-stale This issue can never become stale ❓ clarification required self-hosted team: webapp Issue belongs to the WebApp team

Comments

@mrsimonemms
Copy link
Contributor

mrsimonemms commented Sep 12, 2022

When attempting to create a new Git integration on a proxied server, the test to see if a host is reachable does not get routed through the proxy.

There are a few possible reasons why this may be the case:

  1. the is-reachable library doesn't support it explicitly (although it looks like got does)
  2. does the call get made from the server or browser? If browser, this won't respect the routing
  3. I may not have added the correct configuration for this package in [installer]: add HTTP_PROXY envvars to the Installer #12726

This ticket aims to see what can be done to support Gitpod installations that use a proxy server for their public internet access and ensure that we can support this with enterprise installations.

@mrsimonemms mrsimonemms added the team: webapp Issue belongs to the WebApp team label Sep 12, 2022
@geropl
Copy link
Member

geropl commented Sep 15, 2022

@mrsimonemms Can you share any timeline on when we plan to over proxy support? Somehow that went past me, completely. I'd even go so far and question the decision to support it in the first place. Feels like we pushing an infrastructure concern into the product, really... 😕

/cc @corneliusludmann

@mrsimonemms
Copy link
Contributor Author

@geropl timelines are not really set yet - in reality, I think the official answer is "shortly after the first paying customer requires this feature".

I agree that we don't want to be putting infrastructure concerns into the application. Largely, this is not the infrastructure side of things but it's making sure that the application respects the settings so that it can be installed in this environment and work as expected. In that respect, I view it similar to airgapped - we don't tell people how to build an airgapped environment, we just ensure that it works in that type of environment.

This morning, I wrote a document of Self-Hosted definitions which may be relevant here in explaining our meaning.

@stale
Copy link

stale bot commented Dec 16, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Dec 16, 2022
@mrsimonemms mrsimonemms added meta: never-stale This issue can never become stale and removed meta: stale This issue/PR is stale and will be closed soon labels Jan 21, 2023
@mrsimonemms mrsimonemms closed this as not planned Won't fix, can't repro, duplicate, stale Jun 27, 2023
@github-project-automation github-project-automation bot moved this to In Validation in 🍎 WebApp Team Jun 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta: never-stale This issue can never become stale ❓ clarification required self-hosted team: webapp Issue belongs to the WebApp team
Projects
Status: In Validation
Development

No branches or pull requests

2 participants