Support telemetry for Red Hat VS Code extensions in Eclipse Che

[ericwill]

Is your task related to a problem? Please describe.

In order to enable telemetry support in Che, we need to add the vscode-commons vsix to all Che plugins in the plugin registry.

Describe the solution you'd like

Since all plugins in the registry should have this vsix in their extensions list, it's something we can add at build time. Perhaps something like:

• Create a defaultExtensions.json in the root of the plugin registry. This file will contain a list of vsix files that should be present in all Che plugin registry entries
• Modify the che-plugin-registry build process to automatically append any vsix listed in defaultExtensions.json to the extensions field of every generated meta.yaml file

Describe alternatives you've considered

Manual addition of the vscode-commons vsix file to all Che plugin entries in che-theia-plugins.yaml

Additional context

[ericwill]

@fbricon is the expectation that the vscode-commons plugin will work if there are multiple instances of it running in the same workspace? If so we could just naively add it to every supported plugin entry. However if it's a problem, then we'll have to figure out a way so that there is only ever one running instance of the plugin in any given workspace.

[tsmaeder]

Is there anything special in the commons extensions that would prevent us from just running it as a built-in extension in the theia back-end? Extensions API can be invoked remotely.

[fbricon]

I believe not a single VS Code extension out there is expected to work properly when multiple instances are running concurrently. I don't even know how it'll behave or how we'd mitigate issues.

Having a single extension across the whole installation is definitely the safest

[ericwill]

I believe not a single VS Code extension out there is expected to work properly when multiple instances are running concurrently. I don't even know how it'll behave or how we'd mitigate issues.

Having a single extension across the whole installation is definitely the safest

Do you know if there are any concerns about it not running in the same container as an extension? Otherwise we can enable this trivially by making it a che-theia built-in, as Thomas has suggested.

[benoitf]

AFAIK It can't be part of che-theia built-in for Che, it's not a mandatory extension at all just a Red Hat specific extension (built-in plug-in is what is default on VS Code), .

[ericwill]

AFAIK It can't be part of che-theia built-in for Che, it's not a mandatory extension at all just a Red Hat specific extension (built-in plug-in is what is default on VS Code), .

Do you have an alternative proposal? New Red Hat plugins (like vscode-xml) are failing to launch if vscode-commons is not installed. Soon this will be the case for all Red Hat plugins. Do we have some way to detect that a workspace has plugins with publisher: redhat and install it workspace start?

[tsmaeder]

@benoitf good point: requiring red hat stuff for an Eclipse project is bad form. What's the state of inter-che-plugin dependencies these days?

[ericwill]

I don't mind investigating alternatives, but I also don't object to adding it as a built-in if there are no possible alternatives. Not having this plugin installed is blocking us from upgrading other extensions.

[sympatheticmoose]

For what its worth, it seems that installing vscode-commons by itself doesn't really do anything as far as a user is concerned. It is only activated by the extensions which depend on it.

[l0rd]

@ericwill closing because the PR has been merged. Feel free to reopen if needed.

[vinokurig]

I've tried to start the lates openshift-connector plugin:

apiVersion: 1.0.0
metadata:
  name: wksp-ezioz
components:
  - type: chePlugin
    reference: 'https://gist.github.com/vinokurig/b1eb70baca6ddf96025743cbe0444f88/raw/a0d89a96c25cb1a534963ec93f94717b0e2e8317/plugin-meta.yaml'

and it fails because of the redhat.vscode-commons plugin:

[vinokurig]

@benoitf could you please check it?

[themr0c]

Release notes: https://issues.redhat.com/browse/CRW-1818

[ericwill]

I suppose we should wait until the vscode-commons extension is removed. The other option is that we include the vscode-commons extension in the openshift-connector plugin definition. @benoitf WDYT?

[benoitf]

Openshift connector has removed the dependency to vscode-commons
redhat-developer/vscode-openshift-tools@f22a6d3
but it has not yet released a new version but I would say it'll be done pretty soon.

I think that if we include commons extension in the openshift connector, it will collide with the plugin added by default by che-server (so should be removed first)

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.