Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 6. Configuring Visual Studio Code - Open Source ("Code - OSS")
Learn how to configure Visual Studio Code - Open Source ("Code - OSS").
6.1. Configuring single and multiroot workspaces Link kopierenLink in die Zwischenablage kopiert!
With the multi-root workspace feature, you can work with multiple project folders in the same workspace. This is useful when you are working on several related projects at once, such as product documentation and product code repositories.
See What is a VS Code workspace for better understanding and authoring the workspace files.
The workspace is set to open in multi-root mode by default.
Once workspace is started, the /projects/.code-workspace workspace file is generated. The workspace file will contain all the projects described in the devfile.
If the workspace file already exist, it will be updated and all missing projects will be taken from the devfile. If you remove a project from the devfile, it will be left in the workspace file.
You can change the default behavior and provide your own workspace file or switch to a single-root workspace.
Procedure
Provide your own workspace file.
Put a workspace file with the name
.code-workspaceinto the root of your repository. After workspace creation, the Visual Studio Code - Open Source ("Code - OSS") will use the workspace file as it is.Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantBe careful when creating a workspace file. In case of errors, an empty Visual Studio Code - Open Source ("Code - OSS") will be opened instead.
ImportantIf you have several projects, the workspace file will be taken from the first project. If the workspace file does not exist in the first project, a new one will be created and placed in the
/projectsdirectory.
Specify alternative workspace file.
Define the VSCODE_DEFAULT_WORKSPACE environment variable in your devfile and specify the right location to the workspace file.
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/projects/project-name/workspace-file"env: - name: VSCODE_DEFAULT_WORKSPACE value: "/projects/project-name/workspace-file"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Open a workspace in a single-root mode.
Define VSCODE_DEFAULT_WORKSPACE environment variable and set it to the root.
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2. Configure trusted extensions for Microsoft Visual Studio Code Link kopierenLink in die Zwischenablage kopiert!
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>" ]
"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>"env: - name: VSCODE_TRUSTED_EXTENSIONS value: "<publisher1>.<extension1>,<publisher2>.<extension2>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Mount a ConfigMap with VSCODE_TRUSTED_EXTENSIONS environment variable:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
-
The value of the variable will be parsed on the workspace startup and the corresponding
trustedExtensionAuthAccesssection will be added to theproduct.json.
6.3. Configure default extensions Link kopierenLink in die Zwischenablage kopiert!
Default extensions are a pre-installed set of extensions, specified by putting the extension binary .vsix file path to the DEFAULT_EXTENSIONS environment variable.
After startup, the editor checks for this environment variable, and if it is specified, takes the path to the extensions and installs it in the background without disturbing the user.
Configuring default extensions is useful for installing .vsix extensions from the editor level.
If you want to specify multiple extensions, separate them by semicolon.
DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
Read on to learn how to define the DEFAULT_EXTENSIONS environment variable, including multiple examples of adding .vsix files to your workspace.
There are three different ways to embed default .vsix extensions into your workspace:
- Put the extension binary into the source repository.
-
Use the devfile
postStartevent to fetch extension binaries from the network. -
Include the extensions'
.vsixbinaries in theche-codeimage.
Putting the extension binary into the source repository
Putting the extension binary into the Git repository and defining the environment variable in the devfile is the easiest way to add default extensions to your workspace. If the extension.vsix file exists in the repository root, you can set the DEFAULT_EXTENSIONS for a tooling container.
Procedure
Specify DEFAULT_EXTENSIONS in your
.devfile.yamlas shown in the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Using the devfile postStart event to fetch extension binaries from the network
You can use cURL or GNU Wget to download extensions to your workspace. For that you need to:
- specify a devfile command to download extensions to your workpace
-
add a
postStartevent to run the command on workspace startup - define the DEFAULT_EXTENSIONS environment variable in the devfile
Procedure
Add the values shown in the following example to the devfile:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow WarningIn some cases curl may download a
.gzipcompressed file. This might make installing the extension impossible. To fix that try to save the file as a .vsix.gz file and then decompress it with gunzip. This will replace the .vsix.gz file with an unpacked .vsix file.curl https://some-extension-url --location -o /tmp/extension.vsix.gz gunzip /tmp/extension.vsix.gz
curl https://some-extension-url --location -o /tmp/extension.vsix.gz gunzip /tmp/extension.vsix.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Including the extensions .vsix binaries in the che-code image.
With default extensions bundled in the editor image, and the DEFAULT_EXTENSIONS environment variable defined in the ConfigMap, you can apply the default extensions without changing the devfile.
Following the steps below to add the extensions you need to the editor image.
Procedure
-
Create a directory and place your selected
.vsixextensions in this directory. Create a Dockerfile with the following content:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Build the image and then push it to a registry:
docker build -t yourname/che-code:next . docker push yourname/che-code:next
$ docker build -t yourname/che-code:next . $ docker push yourname/che-code:nextCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the new ConfigMap to the user’s project, define the DEFAULT_EXTENSIONS environment variable, and specify the absolute paths to the extensions. This ConfigMap sets the environment variable to all workspaces in the user’s project.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a workspace using
yourname/che-code:nextimage. First, open the dashboard and navigate to the Create Workspace tab on the left side.- In the Editor Selector section, expand the Use an Editor Definition dropdown and set the editor URI to the Editor Image.
- Create a workspace by clicking on any sample or by using a Git repository URL.
6.4. Applying editor configurations Link kopierenLink in die Zwischenablage kopiert!
You can configure Visual Studio Code - Open Source editor by adding configurations to a ConfigMap. These configurations are applied to any workspace you open. Once a workspace is started, the editor checks for this ConfigMap and stores configurations to the corresponding config files.
The following sections are currently supported:
- settings.json
- extensions.json
- product.json
- configurations.json
The settings.json section contains various settings with which you can customize different parts of the Code - OSS editor.
The extensions.json section contains recommended extensions that are installed when a workspace is started.
The product.json section contains properties that you need to add to the editor’s product.json file. If the property already exists, its value will be updated.
The configurations.json section contains properties for Code - OSS editor configuration. For example, you can use the extensions.install-from-vsix-enabled property to disable Install from VSIX command.
Procedure
Add a new ConfigMap to the user’s project, define the supported sections, and specify the properties you want to add.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Start or restart your workspace
Make sure that the Configmap contains data in a valid JSON format.
Consider adding the ConfigMap to the openshift-devspaces namespace. By adding it to the namespace, you replicate the ConfigMap across all user namespaces while preventing modifications within user’s namespaces. See Section 4.2.3, “Configuring a user namespace”.
Verification
Verify that settings defined in the ConfigMap are applied using one of the following methods:
-
Use
F1to check if the defined settings are applied.Preferences: Open Remote Settings -
Ensure that the settings from the ConfigMap are present in the
/checode/remote/data/Machine/settings.jsonfile by using theF1command to inspect the file’s content.File: Open File…
-
Use
Verify that extensions defined in the ConfigMap are applied:
-
Go to the
Extensionsview (F1) and check that the extensions are installedView: Show Extensions -
Ensure that the extensions from the ConfigMap are present in the
.code-workspacefile by using theF1command. By default, the workspace file is placed atFile: Open File… /projects/.code-workspace.
-
Go to the
Verify that product properties defined in the ConfigMap are being added to the Visual Studio Code product.json:
-
Open a terminal, run the command
cat /checode/entrypoint-logs.txt | grep -a "Node.js dir"and copy the Visual Studio Code path. -
Press
Ctrl + O, paste the copied path and open product.json file. - Ensure that product.json file contains all the properties defined in the ConfigMap.
-
Open a terminal, run the command
Verify that
extensions.install-from-vsix-enabledproperty defined in the ConfigMap is applied to the Code - OSS editor:-
Open the Command Palette (use
F1) to check thatInstall from VSIXcommand is not present in the list of commands. -
Use
F1to open theOpen View Extensions Extensionspanel, then click…on the view (Views and More Actionstooltip) to check thatInstall from VSIXaction is absent in the list of actions. -
Go to the Explorer, find a file with the
vsixextension (redhat.vscode-yaml-1.17.0.vsix, for example), open menu for that file.Install from VSIXaction should be absent in the menu.
-
Open the Command Palette (use