You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tl,dr; we don't honor no_proxy when cloning dotfiles.
Supervisor copies https_proxy and http_proxy into the git clone subroutine, but ignores the no_proxy value.
For users whose SCM instances that host their dotfiles repo are behind the proxies, this is not a problem. But for users whose scm instances aren't behind the proxy and are on the no_proxy list, the dotfiles clone will fail because we explicitly create an empty environment and only set certain variables for it.
The result is the user can clone the repository once their workspace has launched, but the dotfiles won't clone during workspace launch.
This will cause significant issues unless addressed before self-hosted supports https_proxy
Steps to reproduce
Set a user environment variable setting a proxy, also set the no_proxy escaping your-github.com.
Attempt to launch a workspace with your user settings for dotfiles at your-github.com/me/dotfiles
Workspace affected
No response
Expected behavior
Wherever we apply https_proxy environment variables, we must check and apply no_proxy environment variables.
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.
Bug description
tl,dr; we don't honor no_proxy when cloning dotfiles.
Supervisor copies https_proxy and http_proxy into the git clone subroutine, but ignores the no_proxy value.
For users whose SCM instances that host their dotfiles repo are behind the proxies, this is not a problem. But for users whose scm instances aren't behind the proxy and are on the no_proxy list, the dotfiles clone will fail because we explicitly create an empty environment and only set certain variables for it.
The result is the user can clone the repository once their workspace has launched, but the dotfiles won't clone during workspace launch.
This will cause significant issues unless addressed before self-hosted supports https_proxy
Steps to reproduce
Set a user environment variable setting a proxy, also set the no_proxy escaping your-github.com.
Attempt to launch a workspace with your user settings for dotfiles at your-github.com/me/dotfiles
Workspace affected
No response
Expected behavior
Wherever we apply https_proxy environment variables, we must check and apply no_proxy environment variables.
Example repository
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: