Create VSCode extension broker for Theia

[garagatyi]

Description

We need Che 7 plugin broker that would start compatible VSCode extension as Theia plugin in a sidecar container. This would allow us to leverage existing VSCode extensions in Che Theia.
The flow:

1. meta.yaml of a plugin specifies VSCode extension URL
2. Identifier of the Che plugin for that would be VSCode extension
3. meta.yaml of a plugin specifies docker image of a sidecar needed to run extension as Theia remote plugin
4. VSCode extension broker uses this info to add sidecar into workspace configuration, download the extension and copy it to sidecar container (and Theia container too at the moment).

Example of meta.yaml:

id: che-service-plugin
version: 0.0.1
type: VS Code extension
name: k8s extension
title: k8s extension
description: k8s extension
icon: https://www.eclipse.org/che/images/ico/16x16.png
attributes:
 - container-image: dockerhub.io/garagatyi/kubectlnode:latest
 - extension: vscode:extension/ms-kubernetes-tools.vscode-kubernetes-tools

PRs:
Broker code eclipse-che/che-plugin-broker#19
Broker integration in Che #12149
Adding it to the plugin registry eclipse-che/che-plugin-registry#66

Known issues:
VS Code extension call commands execution in main Theia container even when the extension and its dependencies are in a sidecar container #12292
Remote extension runner doesn't copy env vars of a sidecar container to extension Node.js process #12298
It is not possible to run several workspaces with remote plugins #12336

Reproduction Steps

OS and version:

Diagnostics:

[garagatyi]

@l0rd @benoitf WDYT about meta.yaml format?

[l0rd]

Related to #11980

[l0rd]

@garagatyi I am ok with the format I guess. The only thing is that in your example we don't understand if the VSCode extension is a "k8s extension" (in name and title) or a "pull request extension" (in the URL). You may want to make it consistent to avoid confusion.

[garagatyi]

@l0rd sorry, my bad. I was thinking about one particular example of k8s extension but copied PR extension URL. I fixed the URL

[benoitf]

I've updated the link of vscode extension to be vscode:extension/ms-kubernetes-tools.vscode-kubernetes-tools which is a link instead of ext install ms-kubernetes-tools.vscode-kubernetes-tools which was more an instruction

[garagatyi]

@benoitf Could you describe what has to be done to allow Theia use VSCode extension?

• env vars
• ports
• what and where to copy/download
• what is the difference with the brokering of Theia remote plugins

[garagatyi]

I mean remote ones

[benoitf]

@garagatyi I would say it's the same than for Theia plug-ins

• same env vars (extracting plugin's name data from package.json) (same logic than theia)
• ports : same approach
• copy/download : .vsix file to be copied (instead of .theia)
• no difference

[garagatyi]

@benoitf thanks!

[benoitf]

@garagatyi I forgot one thing.
Like for theia files, broker needs to unpack the vsix file (else the mapping of files will be different between the main theia process and the remote processes)

[garagatyi]

@benoitf is there a local case where we don't need to unpack the extension?

[garagatyi]

@l0rd should we use existing filed url for vscode extension or use extension inside of attributes?
VS Code extension example is: vscode:extension/ms-kubernetes-tools.vscode-kubernetes-tools

[l0rd]

I would rather use extension inside of attributes. And I am thinking that publishing/consuming plugins as container images rather than tar.gz hosted at some url may be a better idea too. It would make it easier to release new versions and trigger an update to the plugin-registry automatically.

[garagatyi]

In the case of VS Code extension, we were thinking that users might want to point to an existing extension in the marketplace without owning it and having the right to redistribute it.
Am I missing something?

[l0rd]

Yes I am not talking about VS Code extensions. Developers of VS Code Extensions already have a great platform to publish their plugins.

No I was thinking about how developers of theia (.theia file) and che plugins (tar.gz with a che-plugin.yaml) publish and distribute their plugins. Using GitHub releases works but it's not straightforward, you cannot setup triggers associated with it and not everybody use GitHub (e.g. in the enterprise). So I was wondering if it wouldn't be a better idea to use container registries as a publishing and distribution platform (e.g. a docker image that contains the .theia files and che-plugin.yaml).

[garagatyi]

You are talking about delivery containers, not runtime, right?

[l0rd]

Yes correct. Using a container to package and transport the files (as a tar.gz). Not as a runtime to execute the plugin.

[benoitf]

@l0rd for just plain javascript plug-in (majority of plug-ins) I think they should just go to a marketplace, not be packaged inside containers

[ibuziuk]

@garagatyi could you please link all the existing PRs to the issue ?

[garagatyi]

@ibuziuk sure.
PRs:
Broker code eclipse-che/che-plugin-broker#19
Broker integration in Che #12149
Adding it to the plugin registry eclipse-che/che-plugin-registry#66

Known issues:
VS Code extension call commands execution in main Theia container even when the extension and its dependencies are in a sidecar container #12292
Remote extension runner doesn't copy env vars of a sidecar container to extension Node.js process #12298
It is not possible to run several workspaces with remote plugins #12336

Also added to the issue description