Introduce new remote server flag to always redirect default extension installation to workbench

[sandy081]

I see users are having remote set up with limited network connectivity. In such cases they can configure to install extensions on remote by downloading them locally enabling setting - remote.downloadExtensionsLocally. This will download extensions locally and install the downloaded extensions in the remote.

But I see dev containers and remote SSH extensions start servers on remote with passing extensions to install on start up. If remote cannot support installing extension (recently have issues with signing verifications), then this is can lead to remote not working or taking long time to start or with some bad experience.

Hence, I would recommend remote extensions not to start server with installing extensions in these situation and install the extension after starting the server via client.

[chrmarti]

@sandy081 "install via client" would be using the VS Code CLI on the remote or locally?

[sandy081]

Via client => Locally. There is a command to install extension which you can use to install.

[sandy081]

I can also provide a new command that can do bulk install of extensions.

[jzyrobert]

I'm in support of this idea/behaviour, have a related open ticket: #9090

[roblourens]

How do I know that I'm in this situation, do we need to test connectivity (in bash/powershell) here? Can the CLI do this and fail more gracefully when the extension can't be installed? It just seems easier to implement on that end.

[chrmarti]

I guess we could by the remote.downloadExtensionsLocally setting. What might work more seamless for the user though is if the server would remember which extensions should be installed when downloads fail and let the UI do the downloading once it connects to the server.

[roblourens]

That extension can be configured on the remote, meaning the resolver can't necessarily read it before connecting and deciding whether to install extensions.

[sandy081]

That extension can be configured on the remote

Can you please describe more?

My proposal here is to install extensions on remote via client after connecting to the remote

[roblourens]

Sorry, I meant 'setting', just that we can't check that setting while running the resolver.

The reason we've wanted to do this via the CLI before fully connecting is that we can avoid having to reload the window again after extensions get installed.

[Blues-star]

I have a question, vscode should currently support remote server development in a restricted network environment (without Internet connectivity), right?

[sandy081]

The reason we've wanted to do this via the CLI before fully connecting is that we can avoid having to reload the window again after extensions get installed.

I do not think a reload is required when extensions are installed. They can be enabled immediately.

[joshspicer]

numerous open issues related for SSH: #5927 (comment), #9090, #9454

[chrmarti]

I think for Dev Containers configuring the proxy in Docker should make it work (https://docs.docker.com/engine/cli/proxy/). Docker will then set env variables on all containers that are also passed to the server startup. This only supports basic auth though.

The other remote extensions could pick up the proxy env variables from probing shell env variables.

[joshspicer]

Working on a solution here: microsoft/vscode#238815

[joshspicer]

We have a fallback mechanism now for when --install-extension is used on server launch, but for whatever reason the extension fails to install.

In my testing (where I deny access to the marketplace on the remote), things work great. I can imagine there are other network configurations (silently dropping or allowing the request to timeout?) that perhaps would still cause problems

Closed this issue as tracking that work