Enable to pre-install private `.vsix` extension from the workspace

[Mrazator]

Is your feature request related to a problem? Please describe

Currently, it is allowed to define in gitpod.yml only extensions from public locations - Open VSX registry or public URL. However, it is not possible to target a private extension which is not meant for public use.

Describe the behaviour you'd like

In addition to the installation from the Open VSX registry and any public location, allow the installation from within the workspace, similar to the example below:

vscode:
  extensions:
    - svelte.svelte-vscode
    - bradlc.vscode-tailwindcss@0.6.11
    - https://example.com/abc/releases/extension-0.26.0.vsix
    - file:///workspace/path/to/extension.vsix

Describe alternatives you've considered

1. Running gp-code --install-extension /workspace/path/to/extension.vsix in command phase is a workaround for now, but it takes tens of seconds until the workspace gets initialised and until the VS Code Server is ready, which is unacceptable for our use.
2. Copying content of .vsix inside /workspace/.vscode-remote/extensions in init phase does not work because of the extension dependencies which are not recognized, even though they are preinstalled and defined in vscode.extensions - this throws the same error as described in https://github.com/microsoft/vscode/issues/149309. After the VS Code gets manually reloaded, everything seems fine.
3. Setting GITPOD_EXTERNAL_EXTENSIONS env variable unsurprisingly does not recognize the file protocol, but neither does it recognize a Unique Identifier of an existing public extension - this is not much documented, maybe it was not intended for such use, but it was worth a try.

[akosyakov]

cc @jeanp413 I believe it is supported now by remote cli for built-in extensions: https://github.com/microsoft/vscode-docs/blob/main/remote-release-notes/v1_77.md#install-additional-built-in-extensions-via-vsix

[akosyakov]

Running gp-code --install-extension /workspace/path/to/extension.vsix in command phase is a workaround for now, but it takes tens of seconds until the workspace gets initialised and until the VS Code Server is ready, which is unacceptable for our use.

It is weird. VS Code extensions are installed async and don't block anything as far as I know.

[loujaybee]

Thanks for the feedback @Mrazator and the detailed write-up, I have a couple follow up questions! 🙏

Question 1: I've heard requests of being able to install a global extension for an entire team, or organisation. Is your use case similar to that? Or do you need more fine control over this extension and for who it's installed for?

• Similar to: https://github.com/gitpod-io/gitpod/issues/16293

but it takes tens of seconds until the workspace gets initialised and until the VS Code Server is ready, which is unacceptable for our use.

Question 2: Is there anything about the specifics of your use case that means waiting causes added difficulty?

[Mrazator]

It is weird. VS Code extensions are installed async and don't block anything as far as I know.

@akosyakov That is true, the extensions are installed in a non-blocking way, but there are few additional things:

1. VS Code Server needs to be ready since that's where the extension gets installed - and that takes some time once you open new workspace - it is not immediate, the command needs to wait for the server until it becomes responsive
2. The installation itself is not immediate, it again takes some time and the workspace is unusable without our extension. In other words, users can browse through the file explorer and open files in text editors in the meantime (since the installation is async), but it is useless for them without the extension being installed. Our extension adds specific navigation explorers (instead of file explorer) and graphical editors (instead of text editors) - without those, the user cannot do anything. I believe this also answers @loujaybee's Question 2 - this is our specific use case.

@loujaybee regarding Question 1, it is similar, but I believe we need more control here. First of all, the extension is private, so it is not available in Microsoft Marketplace or in the Open VSX registry. Second of all, the extension is the same across organisations and projects, but the version of the extension is different per workspace (~each branch in the project can have a different version).

We keep the information which version of the extension to install in GIT (imagine VERSION file with semver value), so in the init we download the extension with this specific VERSION and in the command we install it.

Therefore, if we could specify a path to the extension in the workspace where we downloaded the extension in the init phase (i.e. like this file:///workspace/path/to/extension.vsix), we would be able to still dynamically control this versioning issue while "preinstallation" would be performed by Gitpod .

[akosyakov]

VS Code Server needs to be ready since that's where the extension gets installed - and that takes some time once you open new workspace - it is not immediate, the command needs to wait for the server until it becomes responsive

@jeanp413 is it true? I though --install-extension don't need VS Code Server at all to be running but then also in 99% it starts under 1s.

The installation itself is not immediate, it again takes some time and the workspace is unusable without our extension....

To be clear extension listed from .gitpod.yml are installed on startup of workspace as well. If you really want performance boost I think you need enable prebuilds and add init command which install your extension in this case any workspace started from the prebuild as a consequence will have it already installed.

I think it could be a good requirement though that during prebuild we preinstall extensions from .gitpod.yml too.

[Mrazator]

To be clear extension listed from .gitpod.yml are installed on startup of workspace as well.

Maybe there is a different reason and waiting for the VS Code Server is not the main bottleneck. On average it takes around 1 min after VS Code is opened to install our extension.

One reason could be that our extension waits for its dependencies to be installed first, since we assumed those listed in .gitpod.yml are preinstalled and not installed on startup.

If you really want performance boost I think you need enable prebuilds and add init command which install your extension in this case any workspace started from the prebuild as a consequence will have it already installed.

How would you install the extension in init phase if you don't have to VS Code Server available? We tried this hack as mentioned above 2. Copying content of .vsix inside /workspace/.vscode-remote/extensions, but we got issue leading to the need for VS Code reload - probably also caused by having the extensionDependencies .

[jeanp413]

@jeanp413 is it true? I though --install-extension don't need VS Code Server at all to be running

yep using --install-extension does not need the server to be running

VS Code Server needs to be ready, the command needs to wait for the server until it becomes responsive users can browse through the file explorer and open files in text editors in the meantime

@Mrazator could you clarify what you mean with waiting for vscode to be ready? once you start seeing the vscode workbench then vscode is ready (maybe it takes a couple seconds for the extension host to start) and as you said you can browse through the file explorer so vscode is ready at that time

One reason could be that our extension waits for its dependencies to be installed first

yeah that could be it and also maybe you are bottlenecked by cpu if you have some heavy task running on startup or maybe some extension lsp, so this could make the installation of extensions in gitpod.yml slower

[akosyakov]

How would you install the extension in init phase if you don't have to VS Code Server available? We tried this hack as mentioned above 2. Copying content of .vsix inside /workspace/.vscode-remote/extensions, but we got issue leading to the need for VS Code reload - probably also caused by having the extensionDependencies .

Calling code --instal-extension should not need VS Code Server. It will download an extension, put it in the proper location, update manifest and exit. On real workspace VS Code Server will scan the location and manifest and pick it up.

[akosyakov]

To make a progress maybe we need some reproducible example to feel for us actual performance pain, so we can experiment 🤔

I don't mind supporting file scheme though and preinstall extensions as part of prebuild. It is aligned with an idea of prebuild to prepare slow things ahead of time. But maybe there is a better way if we understand the extension causing the issue better.

[Mrazator]

For now, I can share with you the configuration and execution of the command, which performs two calls of the code command (--list-extensions, --install-extension), which should be almost immediate, but for some reason aren't, and thus it takes around 1 min.

Here it is visible it takes around 26s to pass through --list-extensions and another 31s to pass through --install-extension.

I already mentioned that the extension itself has extensionDependencies, so it might be possible it waits for them first to be installed. Also, it is worth mentioning that there are two tasks running in parallel, so it might be possible that the first task just takes too many resources and slows down the second one.

Unfortunately, I did not have much time to investigate further, I will try to add a minimal reproduction, but since multiple factors can cause this, I don't know if (and when) I will succeed.

I don't mind supporting file scheme though and preinstall extensions as part of rebuild.

Either way, this would solve it for good.

[stale[bot]]

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.