Search

Chapter 4. Managing IDE extensions

download PDF

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 the CheCluster 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, use openVSXURL: ''. 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.

Tip

To get the latest security fixes after a OpenShift Dev Spaces update, rebuild your container based on the latest tag or SHA.

Procedure

  1. Get the publisher and extension names of each chosen extension:

    1. Find the extension on the Open VSX registry website and copy the URL of the extension’s listing page.
    2. Extract the <publisher> and <extension> names from the copied URL:

      https://www.open-vsx.org/extension/<publisher>/<extension>
      Tip

      If 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.

  2. Download or fork and clone the plugin registry repository.
  3. Checkout the branch that corresponds to your OpenShift Dev Spaces version:

    git checkout devspaces-$PRODUCT_VERSION-rhel-8
  4. For each extension that you need to add or remove, edit the openvsx-sync.json file:

    • To add extensions, add the publisher and extension names to the openvsx-sync.json file.
    • To remove extensions, remove the publisher and extension names from the openvsx-sync.json file.
    • Use the following JSON syntax:

          {
              "id": "<publisher>.<extension>"
          }
      Tip
      • The latest extension version on open-vsx.org is the default. Alternatively, you can add "version": "<extension_version>" on a new line to specify a version.
      • If 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>.<extension>",
                "download": "<url_to_download_vsix_file>",
                "version": "<extension_version>"
            }
      • Read the Terms of Use for the Microsoft Visual Studio Marketplace before using its resources.
  5. Build the plugin registry container image and publish it to a container registry like quay.io:

    1. $ ./build.sh -o <username> -r quay.io -t custom
    2. $ podman push quay.io/<username/plugin_registry:custom>
  6. 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

  1. Check that the plugin-registry pod has restarted and is running.
  2. 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.

Warning

Use the trustedExtensionAuthAccess field with caution as it could potentially lead to security risks if misused. Give access only to trusted extensions.

Procedure

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.

  1. Define the VSCODE_TRUSTED_EXTENSIONS environment variable. Choose between defining the variable in devfile.yaml or mounting a ConfigMap with the variable instead.

    1. Define the VSCODE_TRUSTED_EXTENSIONS environment variable in devfile.yaml:

         env:
           - name: VSCODE_TRUSTED_EXTENSIONS
             value: "<publisher1>.<extension1>,<publisher2>.<extension2>"
    2. 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 the product.json.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.