yarn download:plugins disregard proxy settings

[Niklas-Dahlquist]

Bug Description:

Latest changes to download-plugins.ts doesn't follow proxy settings

Steps to Reproduce:

Do a yarn download:plugins behind a proxy that requires login in Theia Blueprint, is it caused by Blueprint now since a vscode-builtin bundle was introduced, where the resolving kicks-in?

Fails during this step: download-plugins.ts:125 console.warn('--- resolving extension-packs ---');

--- resolving extension-packs ---
Error: connect ETIMEDOUT 198.41.30.195:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16) {
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '198.41.30.195',
  port: 443
}

• Theia Version: 1.18.0

[vince-fugnitto]

@Niklas-Dahlquist thank you for reporting the issue. Can you confirm if you are able to install extensions at runtime through the extensions-view? The resolvement of extension-packs uses the openvsx-cli to determine the latest compatible extension and is likely the reason it might fail as it might not respect the proxy settings. I suspect that if extensions cannot be installed at runtime through the view then it is an issue with the cli itself that we might need to address support for it.

[Niklas-Dahlquist]

Hi Vincent,
I've tried the Blueprint(1.17.2, with proxy settings) and I can confirm that downloading extensions doesn't work. Get timeouts like this:
root ERROR Failed to resolve plugins from 'vscode:extension/bmo-test.bmo-hello-world' Error: connect ETIMEDOUT 198.41.30.195:443
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1134:16)

[gbodeen]

We're now running into almost the same problem in our CI. The trouble appears to start with the bent library used in dev-packages/ovsx-client/src/ovsx-client.ts that isn't configurable to use proxy settings, from where it is used in the getLatestCompatibleExtensionVersion method, which is in turned called from within dev-packages/cli/src/download-plugins.ts when the yarn download:plugins script is run.

[vince-fugnitto]

@gbodeen that's right, we would need to refactor bent to similarly use what we have in the download:plugins script which supports the proxy settings: #7747.

[ballcoach12]

FWIW, I am seeing the same problem.

[msujew]

Just to give some context how this is fixed: The download:plugins command will automatically pick up the http_proxy and https_proxy env variables. Also, you can manually set the --proxy-url <some http address> argument, which will then take precedence over any existing env variables.