Dotfiles break in some proxy environments

[mrzarquon]

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-git.colasdn.top.

Attempt to launch a workspace with your user settings for dotfiles at your-git.colasdn.top/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

Front conversations

[mrzarquon]

This isn't fixed by #13959, it just prevents that from happening in some cases. The problem still exists.

[subinamathew]

Do you have a lead time on this issue?

[stale]

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.