Chapter 4. Managing IDE extensions
IDEs use extensions or plugins to extend their functionality, and the mechanism for managing extensions differs between IDEs.
4.1. Extensions for Microsoft Visual Studio Code - Open Source
To manage extensions, this IDE uses one of these Open VSX registry instances:
-
The embedded instance of the Open VSX registry that runs in the
plugin-registry
pod of OpenShift Dev Spaces to support air-gapped, offline, and proxy-restricted environments. The embedded Open VSX registry contains only a subset of the extensions published on open-vsx.org. This subset is customizable. - The public open-vsx.org registry that is accessed over the internet.
- A standalone Open VSX registry instance that is deployed on a network accessible from OpenShift Dev Spaces workspace pods.
The default is the embedded instance of the Open VSX registry.
4.1.1. Selecting an Open VSX registry instance
The default is the embedded instance of the Open VSX registry.
If the default Open VSX registry instance is not what you need, you can select one of the following instances:
-
The Open VSX registry instance at
https://open-vsx.org
that requires access to the internet. - A standalone Open VSX registry instance that is deployed on a network accessible from OpenShift Dev Spaces workspace pods.
Procedure
Edit the
openVSXURL
value in theCheCluster
custom resource:spec: components: pluginRegistry: openVSXURL: "<url_of_an_open_vsx_registry_instance>" 1
- 1
- For example:
openVSXURL: "https://open-vsx.org"
.
Tip-
To select the embedded Open VSX registry instance in the
plugin-registry
pod, useopenVSXURL: ''
. You can customize the list of included extensions. -
You can also point
openVSXURL
at the URL of a standalone Open VSX registry instance if its URL is accessible from within your organization’s cluster and not blocked by a proxy.
4.1.2. Adding or removing extensions in the embedded Open VSX registry instance
You can add or remove extensions in the embedded Open VSX registry instance. This results in a custom build of the Open VSX registry that can be used in your organization’s workspaces.
To get the latest security fixes after a OpenShift Dev Spaces update, rebuild your container based on the latest tag or SHA.
Procedure
Get the publisher and extension name of each chosen extension:
- Find the extension on the Open VSX registry website and copy the URL of the extension’s listing page and extension’s version.
Extract the <publisher> and <extension> name from the copied URL:
https://open-vsx.org/extension/<publisher>/<name>
TipIf the extension is only available from Microsoft Visual Studio Marketplace, but not Open VSX, you can ask the extension publisher to also publish it on open-vsx.org according to these instructions, potentially using this GitHub action.
If the extension publisher is unavailable or unwilling to publish the extension to open-vsx.org, and if there is no Open VSX equivalent of the extension, consider reporting an issue to the Open VSX team.
Build the custom plugin registry image and update CheCluster custom resource:
Tip- During the build process, each extension will be verified for compatibility with the version of Visual Studio Code used in OpenShift Dev Spaces.
Using OpenShift Dev Spaces instance:
- Login to your OpenShift Dev Spaces instance as an administrator.
Create a new Red Hat Registry Service Account and copy username and token.
- Start a workspace using the plugin registry repository.
Open a terminal and check out the Git tag that corresponds to your OpenShift Dev Spaces version (e.g.,
devspaces-3.15-rhel-8
):git checkout devspaces-$PRODUCT_VERSION-rhel-8
-
Open the
openvsx-sync.json
file and add or remove extensions. -
Execute
1. Login to registry.redhat.io
task in the workspace (TerminalRun Task… devfile 1. Login to registry.redhat.io) and login to registry.redhat.io. -
Execute
2. Build and Publish a Custom Plugin Registry
task in the workspace (TerminalRun Task… devfile 2. Build and Publish a Custom Plugin Registry). Execute
3. Configure Che to use the Custom Plugin Registry
task in the workspace (TerminalRun Task… devfile 3. Configure Che to use the Custom Plugin Registry). Using Linux operating system:
Tip- Podman and NodeJS version 18.20.3 or higher should be installed in the system.
- Download or fork and clone the Dev Spaces repository.
git clone https://github.com/redhat-developer/devspaces.git
+
- Go to the plugin registry submodule:
cd devspaces/dependencies/che-plugin-registry/
+
Checkout the tag that corresponds to your OpenShift Dev Spaces version (e.g.,
devspaces-3.15-rhel-8
):git checkout devspaces-$PRODUCT_VERSION-rhel-8
- Create a new Red Hat Registry Service Account and copy username and token.
Login to registry.redhat.io:
podman login registry.redhat.io
For each extension that you need to add or remove, edit the
openvsx-sync.json
file:-
To add extensions, add the publisher, name and extension version to the
openvsx-sync.json
file. -
To remove extensions, remove the publisher, name and extension version from the
openvsx-sync.json
file. Use the following JSON syntax:
{ "id": "<publisher>.<name>", "version": "<extension_version>" }
TipIf you have a closed-source extension or an extension developed only for internal use in your organization, you can add the extension directly from a
.vsix
file by using a URL accessible to your custom plugin registry container:{ "id": "<publisher>.<name>", "download": "<url_to_download_vsix_file>", "version": "<extension_version>" }
- Read the Terms of Use for the Microsoft Visual Studio Marketplace before using its resources.
-
To add extensions, add the publisher, name and extension version to the
Build the plugin registry container image and publish it to a container registry such as quay.io:
$ ./build.sh -o <username> -r quay.io -t custom
$ podman push quay.io/<username/plugin_registry:custom>
Edit the
CheCluster
custom resource in your organization’s cluster to point to the image (for example, on quay.io) and save the changes:spec: components: pluginRegistry: deployment: containers: - image: quay.io/<username/plugin_registry:custom> openVSXURL: ''
Verification
-
Check that the
plugin-registry
pod has restarted and is running. - Restart the workspace and check the available extensions in the Extensions view of the workspace IDE.
4.2. Configure trusted extensions for Microsoft Visual Studio Code
You can use the trustedExtensionAuthAccess
field in the product.json
file of Microsoft Visual Studio Code to specify which extensions are trusted to access authentication tokens.
"trustedExtensionAuthAccess": [ "<publisher1>.<extension1>", "<publisher2>.<extension2>" ]
This is particularly useful when you have extensions that require access to services such as GitHub, Microsoft, or any other service that requires OAuth. By adding the extension IDs to this field, you are granting them the permission to access these tokens.
You can define the variable in the devfile or in the ConfigMap. Pick the option that better suits your needs. With a ConfigMap, the variable will be propagated on all your workspaces and you do not need to add the variable to each the devfile you are using.
Use the trustedExtensionAuthAccess
field with caution as it could potentially lead to security risks if misused. Give access only to trusted extensions.
Since the Microsoft Visual Studio Code editor is bundled within che-code
image, you can only change the product.json
file when the workspace is started up.
Define the VSCODE_TRUSTED_EXTENSIONS environment variable. Choose between defining the variable in devfile.yaml or mounting a ConfigMap with the variable instead.
Define the VSCODE_TRUSTED_EXTENSIONS environment variable in devfile.yaml:
env: - name: VSCODE_TRUSTED_EXTENSIONS value: "<publisher1>.<extension1>,<publisher2>.<extension2>"
Mount a ConfigMap with VSCODE_TRUSTED_EXTENSIONS environment variable:
kind: ConfigMap apiVersion: v1 metadata: name: trusted-extensions labels: controller.devfile.io/mount-to-devworkspace: 'true' controller.devfile.io/watch-configmap: 'true' annotations: controller.devfile.io/mount-as: env data: VSCODE_TRUSTED_EXTENSIONS: '<publisher1>.<extension1>,<publisher2>.<extension2>'
Verification
-
The value of the variable will be parsed on the workspace startup and the corresponding
trustedExtensionAuthAccess
section will be added to theproduct.json
.