Procedure

1. Optional: Visit your OpenShift Dev Spaces dashboard pages to authenticate to your organization’s instance of OpenShift Dev Spaces.

2. Enter the URL in your browser or in the Git Repository URL field on the Create Workspace page to start a new workspace:

   https://<openshift_dev_spaces_fqdn>#<git_repository_url>

   Copy code to clipboard

   To append optional parameters, add ?<optional_parameters> to the URL. See Chapter 2, Optional parameters for the URLs for starting a new workspace for supported parameters.

   For example:

   • https://<openshift_dev_spaces_fqdn>#https://github.com/che-samples/cpp-hello-world

   • https://<openshift_dev_spaces_fqdn>#git@github.com:che-samples/cpp-hello-world.git

     URL syntax per Git provider:

     Table 1.1. GitHub

     URL pattern
     Default branch: https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository>
     Specified branch: https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository>/tree/<branch_name>
     Pull request branch: https://<openshift_dev_spaces_fqdn>#https://<github_host>/<user_or_org>/<repository>/pull/<pull_request_id>
     Git+SSH: https://<openshift_dev_spaces_fqdn>#git@<github_host>:<user_or_org>/<repository>.git

     For GitHub, you can also use a URL of a directory containing a devfile, or a direct URL to the devfile. The devfile name must be devfile.yaml or .devfile.yaml. Other Git providers do not support this feature.

     Table 1.2. GitLab

     URL pattern
     Default branch: https://<openshift_dev_spaces_fqdn>#https://<gitlab_host>/<user_or_org>/<repository>
     Specified branch: https://<openshift_dev_spaces_fqdn>#https://<gitlab_host>/<user_or_org>/<repository>/-/tree/<branch_name>
     Git+SSH: https://<openshift_dev_spaces_fqdn>#git@<gitlab_host>:<user_or_org>/<repository>.git

     Table 1.3. Bitbucket Server

     URL pattern
     Default branch: https://<openshift_dev_spaces_fqdn>#https://<bb_host>/scm/<project-key>/<repository>.git
     Default branch (user profile repository): https://<openshift_dev_spaces_fqdn>#https://<bb_host>/users/<user_slug>/repos/<repository>/
     Specified branch: https://<openshift_dev_spaces_fqdn>#https://<bb_host>/users/<user-slug>/repos/<repository>/browse?at=refs%2Fheads%2F<branch-name>
     Git+SSH: https://<openshift_dev_spaces_fqdn>#git@<bb_host>:<user_slug>/<repository>.git

     Table 1.4. Microsoft Azure DevOps

     URL pattern
     Default branch: https://<openshift_dev_spaces_fqdn>#https://<organization>@dev.azure.com/<organization>/<project>/_git/<repository>
     Specified branch: https://<openshift_dev_spaces_fqdn>#https://<organization>@dev.azure.com/<organization>/<project>/_git/<repository>?version=GB<branch>
     Git+SSH: https://<openshift_dev_spaces_fqdn>#git@ssh.dev.azure.com:v3/<organization>/<project>/<repository>

Procedure

1. Optional: Visit your OpenShift Dev Spaces dashboard pages to authenticate to your organization’s instance of OpenShift Dev Spaces.

2. Enter the devfile URL in your browser to start a new workspace.

   For a public repository:

   https://<openshift_dev_spaces_fqdn>#<devfile_url>

   Copy code to clipboard

   For a private repository, include your personal access token in the URL:

   https://<openshift_dev_spaces_fqdn>#https://<token>@<host>/<path_to_devfile>

   Copy code to clipboard

   where:

   <token>

   Your personal access token that you generated on the Git provider’s website. This method works for GitHub, GitLab, Bitbucket, Microsoft Azure, and other providers that support Personal Access Token.

   Important

   Automated Git credential injection does not work with token-embedded URLs. To configure Git credentials separately, see Section 6.6, “Use a Git provider access token”.

   To append optional parameters, add ?<optional_parameters> to the URL. See Chapter 2, Optional parameters for the URLs for starting a new workspace for supported parameters.

   For example:

   • Public repository: https://<openshift_dev_spaces_fqdn>#https://raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml
   • Private repository: https://<openshift_dev_spaces_fqdn>#https://<token>@raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml

Procedure

1. Use the pod-overrides attribute to add the required annotations defined in Configuring fuse-overlayfs to the workspace. The pod-overrides attribute allows merging certain fields in the workspace pod’s spec.

   For OpenShift versions older than 4.15:

   $ oc patch devworkspace <DevWorkspace_name> \
     --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse","io.openshift.podman-fuse":""}}}}}}}' \
     --type=merge

   Copy code to clipboard

   For OpenShift version 4.15 and later:

   $ oc patch devworkspace <DevWorkspace_name> \
     --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse"}}}}}}}' \
     --type=merge

   Copy code to clipboard

Verification

1. Start the workspace and verify that /dev/fuse is available in the workspace container:

   $ stat /dev/fuse

   Copy code to clipboard

Procedure

1. Create a ConfigMap that mounts a /home/user/.config/containers/storage.conf file:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: fuse-overlay
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user/.config/containers
   data:
     storage.conf: |
       [storage]
       driver = "overlay"
   
       [storage.options.overlay]
       mount_program = "/usr/bin/fuse-overlayfs"

   Copy code to clipboard

2. Apply the ConfigMap to your project:

   Warning

   Applying this ConfigMap causes all running workspaces in the project to restart.

   $ oc apply -f fuse-overlay.yaml -n <your_namespace>

   Copy code to clipboard
3. Start or restart your workspace.

Procedure

1. Add KUBEDOCK_ENABLED=true environment variable to the devfile.

2. Optional: Use the KUBEDOCK_PARAMS variable to specify additional kubedock parameters. The list of parameters is available in the Content from github.com is not included.kubedock server source. Alternatively, you can use the following command to view the available options:

   # kubedock server --help

   Copy code to clipboard

3. Configure the Podman or docker API to point to kubedock by setting CONTAINER_HOST=tcp://127.0.0.1:2475 or DOCKER_HOST=tcp://127.0.0.1:2475 in the devfile.

   Important

   Configure Podman to point to local Podman when building containers, and to kubedock when running containers.

   The following example devfile enables kubedock with Testcontainers support:

   schemaVersion: 2.2.0
   metadata:
     name: kubedock-sample-devfile
   components:
     - name: tools
       container:
         image: quay.io/devfile/universal-developer-image:latest
         memoryLimit: 8Gi
         memoryRequest: 1Gi
         cpuLimit: "2"
         cpuRequest: 200m
         env:
           - name: KUBEDOCK_PARAMS
             value: "--reverse-proxy --kubeconfig /home/user/.kube/config --initimage quay.io/agiertli/kubedock:0.13.0"
           - name: USE_JAVA17
             value: "true"
           - value: /home/jboss/.m2
             name: MAVEN_CONFIG
           - value: -Xmx4G -Xss128M -XX:MetaspaceSize=1G -XX:MaxMetaspaceSize=2G
             name: MAVEN_OPTS
           - name: KUBEDOCK_ENABLED
             value: 'true'
           - name: DOCKER_HOST
             value: 'tcp://127.0.0.1:2475'
           - name: TESTCONTAINERS_RYUK_DISABLED
             value: 'true'
           - name: TESTCONTAINERS_CHECKS_DISABLE
             value: 'true'
         endpoints:
           - exposure: none
             name: kubedock
             protocol: tcp
             targetPort: 2475
           - exposure: public
             name: http-booster
             protocol: http
             targetPort: 8080
             attributes:
               discoverable: true
               urlRewriteSupported: true
           - exposure: internal
             name: debug
             protocol: http
             targetPort: 5005
         volumeMounts:
           - name: m2
             path: /home/user/.m2
     - name: m2
       volume:
         size: 10G

   Copy code to clipboard

Procedure

1. Set the DOCKER_HOST environment variable to point to the Kubedock server:

   export DOCKER_HOST=tcp://127.0.0.1:2475

   Copy code to clipboard

2. Start the Kubedock server in the background:

   kubedock server --port-forward &

   Copy code to clipboard

3. Use standard Docker commands that Kubedock handles:

   docker run --rm hello-world

   Copy code to clipboard

Procedure

1. Open the feature branch to review in OpenShift Dev Spaces. A clone of the branch opens in a workspace with tools for debugging and testing.
2. Check the pull or merge request changes.

3. Run your desired debugging and testing tools:

   • Run a linter.
   • Run unit tests.
   • Run the build.
   • Run the application to check for problems.
4. Navigate to the UI of your Git provider to leave a comment and pull or merge your assigned request.

Procedure

1. In the GitHub repository, create a .github/workflows directory if it does not exist already.

2. Create an example.yml file in the .github/workflows directory with the following content:

   name: Try in Web IDE example
   
   on:
     pull_request_target:
       types: [opened]
   
   jobs:
     add-link:
       runs-on: ubuntu-20.04
       steps:
         - name: Web IDE Pull Request Check
           id: try-in-web-ide
           uses: redhat-actions/try-in-web-ide@v1
           with:
             # GitHub action inputs
   
             # required
             github_token: ${{ secrets.GITHUB_TOKEN }}
   
             # optional - defaults to true
             add_comment: true
   
             # optional - defaults to true
             add_status: true

   Copy code to clipboard

   This code snippet creates a workflow named Try in Web IDE example, with a job that runs the v1 version of the redhat-actions/try-in-web-ide community action. The workflow is triggered on the Content from docs.github.com is not included.pull_request_target event, on the opened activity type.

3. Optional: Configure the activity types from the on.pull_request_target.types field to customize when the workflow triggers. Activity types such as reopened and synchronize can be useful.

   For example:

   on:
     pull_request_target:
       types: [opened, synchronize]

   Copy code to clipboard
4. Optional: Configure the add_comment and add_status GitHub action inputs within example.yml. These inputs customize whether comments and status checks are added.

Procedure

1. Create a workspace on the OpenShift Dev Spaces Dashboard and choose IntelliJ IDEA Ultimate (desktop) editor:

   

2. Wait for the prompt to open your local JetBrains Gateway application to appear:

   

3. Click the Open Gateway button to start your local JetBrains Client application connected to your OpenShift Dev Spaces workspace:

   

Procedure

1. Open the Gateway app and click Connect to Dev Spaces:

   

2. Provide the parameters to connect to the OpenShift Application Programming Interface (API) server and click the Check Connection and Continue button:

   

3. Choose your workspace and click the Connect button:

   

Procedure

1. Create a workspace on the OpenShift Dev Spaces Dashboard and choose JetBrains Toolbox App (desktop) as the editor:

   
2. After the workspace is started, copy the oc port-forward …​ command from the opened page. Run the command in your local terminal to forward the remote SSH port to your local machine.

3. On the workspace page, click the Open the workspace over Toolbox link to run the local Toolbox App and initiate the SSH connection to your OpenShift Dev Spaces workspace:

   

4. After the connection is established, click the Cloud Development Environment (CDE) name. On the Tools tab, choose an IDE to install in your workspace:

   

5. After the IDE is installed, on the Projects tab, click the project name to connect the local Thin Client to the workspace:

   

Procedure

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

   1. Find the extension on the Content from www.open-vsx.org is not included.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>

      Copy code to clipboard
2. Create a .vscode/extensions.json file in the remote Git repository.

3. Add the <publisher> and <extension> names to the extensions.json file as follows:

     {
       "recommendations": [
         "<publisher_A>.<extension_B>",
         "<publisher_C>.<extension_D>",
         "<publisher_E>.<extension_F>"
       ]
     }

   Copy code to clipboard

Verification

1. Start a new workspace by using the URL of the remote Git repository that contains the created extensions.json file.
2. In the IDE of the workspace, press Ctrl+Shift+X or go to Extensions to find each of the extensions listed in the file.
3. The extension has the label This extension is enabled globally.

Verification

1. Start a new workspace with a clone of the Git repository.
2. Verify that the specified IDE loads in the browser tab of the started workspace.

Procedure

1. Create a Secret with the required labels and annotations:

   kind: Secret
   apiVersion: v1
   metadata:
     name: my-credentials
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
     annotations:
       controller.devfile.io/mount-as: file
       controller.devfile.io/mount-path: /etc/my-credentials
   type: Opaque
   data:
     api-key: <base64_encoded_api_key>

   Copy code to clipboard

   where:

   controller.devfile.io/mount-to-devworkspace

   Required label to mount the Secret to all workspaces.

   controller.devfile.io/watch-secret

   Watch the Secret for changes and update mounted files.

   controller.devfile.io/mount-as

   Mount type: file, subpath, or env.

   controller.devfile.io/mount-path

   Path where the Secret data is mounted.

2. Apply the Secret to your project:

   $ oc apply -f my-credentials.yaml -n <your_namespace>

   Copy code to clipboard

3. Optional: Add annotations to the Secret to customize the mounting behavior.

   Table 6.1. Secret mounting annotations

   Annotation	Description
   controller.devfile.io/mount-path: <path>	Overrides the default mount path. The default mount path is /etc/secret/<Secret_name>.
   controller.devfile.io/mount-as: file	Each key in the Secret data becomes a file in the mount path directory.
   controller.devfile.io/mount-as: subpath	Similar to file, but uses subPath volumes for better compatibility.
   controller.devfile.io/mount-as: env	Each key-value pair becomes an environment variable in all workspace containers.

   For example, to mount Secret data as environment variables:

   kind: Secret
   apiVersion: v1
   metadata:
     name: my-env-secret
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
     annotations:
       controller.devfile.io/mount-as: env
   type: Opaque
   stringData:
     DATABASE_URL: postgresql://localhost:5432/mydb
     API_SECRET: my-secret-key

   Copy code to clipboard

   For example, to mount a Maven settings.xml file to the /home/user/.m2/ path using subpath:

   kind: Secret
   apiVersion: v1
   metadata:
     name: maven-settings
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
     annotations:
       controller.devfile.io/mount-path: /home/user/.m2/
       controller.devfile.io/mount-as: subpath
   type: Opaque
   stringData:
     settings.xml: |
       <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
       </settings>

   Copy code to clipboard

   After the workspace starts, the /home/user/.m2/settings.xml file is available in the Dev Workspace containers. To use a custom path with Maven, run mvn --settings /home/user/.m2/settings.xml clean install.

4. Start or restart your workspace to apply the mounted Secret.

Procedure

1. In your user project, create an image pull Secret with your private container registry details and credentials:

   $ oc create secret docker-registry <Secret_name> \
       --docker-server=<registry_server> \
       --docker-username=<username> \
       --docker-password=<password> \
       --docker-email=<email_address>

   Copy code to clipboard

2. Add the required labels to the image pull Secret:

   $ oc label secret <Secret_name> controller.devfile.io/devworkspace_pullsecret=true controller.devfile.io/watch-secret=true

   Copy code to clipboard

Procedure

1. Encode the .dockercfg file to Base64:

   $ cat .dockercfg | base64 | tr -d '\n'

   Copy code to clipboard

2. Create a new OpenShift Secret in your user project:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <Secret_name>
     labels:
       controller.devfile.io/devworkspace_pullsecret: 'true'
       controller.devfile.io/watch-secret: 'true'
   data:
     .dockercfg: <Base64_content_of_.dockercfg>
   type: kubernetes.io/dockercfg

   Copy code to clipboard

3. Apply the Secret:

   $ oc apply -f - <<EOF
   <Secret_prepared_in_the_previous_step>
   EOF

   Copy code to clipboard

Procedure

1. Encode the $HOME/.docker/config.json file to Base64:

   $ cat config.json | base64 | tr -d '\n'

   Copy code to clipboard

2. Create a new OpenShift Secret in your user project:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <Secret_name>
     labels:
       controller.devfile.io/devworkspace_pullsecret: 'true'
       controller.devfile.io/watch-secret: 'true'
   data:
     .dockerconfigjson: <Base64_content_of_config.json>
   type: kubernetes.io/dockerconfigjson

   Copy code to clipboard

3. Apply the Secret:

   $ oc apply -f - <<EOF
   <Secret_prepared_in_the_previous_step>
   EOF

   Copy code to clipboard

Procedure

1. Create a Kubernetes Secret with your access token:

   kind: Secret
   apiVersion: v1
   metadata:
     name: personal-access-token-<git_provider>
     labels:
       controller.devfile.io/git-credential: 'true'
       controller.devfile.io/watch-secret: 'true'
     annotations:
       controller.devfile.io/git-credential-host: <git_provider_host>
   type: Opaque
   stringData:
     token: <your_personal_access_token>

   Copy code to clipboard

   where:

   controller.devfile.io/git-credential

   Required label for Git credentials.

   controller.devfile.io/git-credential-host

   The hostname of your Git provider (e.g., github.com, gitlab.com).

   token

   Your personal access token.

   Example for GitHub:

   kind: Secret
   apiVersion: v1
   metadata:
     name: personal-access-token-github
     labels:
       controller.devfile.io/git-credential: 'true'
       controller.devfile.io/watch-secret: 'true'
     annotations:
       controller.devfile.io/git-credential-host: github.com
   type: Opaque
   stringData:
     token: ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

   Copy code to clipboard

2. Apply the Secret to your project:

   $ oc apply -f personal-access-token.yaml -n <your_namespace>

   Copy code to clipboard
3. Start or restart your workspace.

Verification

1. Open a terminal in your workspace.

2. Clone a private repository or push to a repository to verify authentication:

   $ git clone https://github.com/<org>/<private-repo>.git

   Copy code to clipboard

Procedure

1. Create a ConfigMap with the required labels and annotations:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: my-config
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: file
       controller.devfile.io/mount-path: /etc/my-config
   data:
     settings.json: |
       {
         "editor.fontSize": 14,
         "editor.tabSize": 2
       }

   Copy code to clipboard

   where:

   controller.devfile.io/mount-to-devworkspace

   Required label to mount the ConfigMap to all workspaces.

   controller.devfile.io/watch-configmap

   Watch the ConfigMap for changes and update mounted files.

   controller.devfile.io/mount-as

   Mount type: file, subpath, or env.

   controller.devfile.io/mount-path

   Path where the ConfigMap data is mounted.

2. Apply the ConfigMap to your project:

   $ oc apply -f my-config.yaml -n <your_namespace>

   Copy code to clipboard

3. Optional: Add annotations to the ConfigMap to customize the mounting behavior.

   Table 6.2. ConfigMap mounting annotations

   Annotation	Description
   controller.devfile.io/mount-path: <path>	Overrides the default mount path. The default mount path is /etc/config/<ConfigMap_name>.
   controller.devfile.io/mount-as: file	Each key in the ConfigMap data becomes a file in the mount path directory.
   controller.devfile.io/mount-as: subpath	Similar to file, but uses subPath volumes for better compatibility.
   controller.devfile.io/mount-as: env	Each key-value pair becomes an environment variable in all workspace containers.

   For example, to mount ConfigMap data as environment variables:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: my-env-config
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: env
   data:
     LOG_LEVEL: debug
     MAX_CONNECTIONS: "100"

   Copy code to clipboard
4. Start or restart your workspace to apply the mounted ConfigMap.

Procedure

1. Create a ConfigMap with your Git configuration:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: workspace-userdata-gitconfig-configmap
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user
   data:
     .gitconfig: |
       [user]
         name = Your Name
         email = your.email@example.com
       [core]
         editor = vim
       [pull]
         rebase = true

   Copy code to clipboard

2. Apply the ConfigMap to your project:

   $ oc apply -f gitconfig.yaml -n <your_namespace>

   Copy code to clipboard
3. Start or restart your workspace.

Verification

1. Open a terminal in your workspace.

2. Verify the Git configuration:

   $ git config --list

   Copy code to clipboard

Procedure

1. Create a ConfigMap with the SSH configuration:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: workspace-userdata-sshconfig-configmap
     namespace: <your_namespace>
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /etc/ssh/ssh_config.d/
   data:
     ssh-config.conf: |
       <ssh_config_content>

   Copy code to clipboard

   where:

   <your_namespace>

   Your project name. To find your project, go to Content from __<openshift_dev_spaces_fqdn>__ is not included.https://__<openshift_dev_spaces_fqdn>__/api/kubernetes/namespace.

   <ssh_config_content>

   The SSH configuration file content, for example Host, IdentityFile, or ProxyCommand directives.

2. Apply the ConfigMap:

   oc apply -f - <<EOF
   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: workspace-userdata-sshconfig-configmap
     namespace: <your_namespace>
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /etc/ssh/ssh_config.d/
   data:
     ssh-config.conf: |
       <ssh_config_content>
   EOF

   Copy code to clipboard

Procedure

1. Create a Secret to store the TLS certificate:

   kind: Secret
   apiVersion: v1
   metadata:
     name: tls-cer
     annotations:
       controller.devfile.io/mount-path: /home/user/certs
       controller.devfile.io/mount-as: file
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
   data:
     tls.cer: >-
       <Base64_encoded_content_of_public_cert>

   Copy code to clipboard

   where:

   <Base64_encoded_content_of_public_cert>

   The Base64-encoded content of your Maven artifact repository’s public TLS certificate, with line wrapping disabled.

2. Apply the Secret to the <username>-devspaces namespace:

   $ oc apply -f tls-cer.yaml -n <username>-devspaces

   Copy code to clipboard

3. Create a ConfigMap for the settings.xml file:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: settings-xml
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user/.m2
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
   data:
     settings.xml: |
       <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
         <localRepository/>
         <interactiveMode/>
         <offline/>
         <pluginGroups/>
         <servers/>
         <mirrors>
           <mirror>
             <id>redhat-ga-mirror</id>
             <name>Red Hat GA</name>
             <url>https://<maven_artifact_repository_route>/repository/redhat-ga/</url>
             <mirrorOf>redhat-ga</mirrorOf>
           </mirror>
           <mirror>
             <id>maven-central-mirror</id>
             <name>Maven Central</name>
             <url>https://<maven_artifact_repository_route>/repository/maven-central/</url>
             <mirrorOf>maven-central</mirrorOf>
           </mirror>
           <mirror>
             <id>jboss-public-repository-mirror</id>
             <name>JBoss Public Maven Repository</name>
             <url>https://<maven_artifact_repository_route>/repository/jboss-public/</url>
             <mirrorOf>jboss-public-repository</mirrorOf>
           </mirror>
         </mirrors>
         <proxies/>
         <profiles/>
         <activeProfiles/>
       </settings>

   Copy code to clipboard

   where:

   <maven_artifact_repository_route>

   The hostname and path of your internal Maven artifact repository.

4. Optional: When using JBoss EAP-based devfiles, create a second settings-xml ConfigMap with a different name and the /home/jboss/.m2 mount path. Use the same content as step 3.

5. Create a ConfigMap for the TrustStore initialization script that matches your Java version:

   For Java 8:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: init-truststore
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user/
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
   data:
     init-java8-truststore.sh: |
       #!/usr/bin/env bash
   
       keytool -importcert -noprompt -file /home/user/certs/tls.cer -trustcacerts -keystore ~/.java/current/jre/lib/security/cacerts -storepass changeit

   Copy code to clipboard

   For Java 11:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: init-truststore
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user/
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
   data:
     init-java11-truststore.sh: |
       #!/usr/bin/env bash
   
       keytool -importcert -noprompt -file /home/user/certs/tls.cer -cacerts -storepass changeit

   Copy code to clipboard

6. Apply the Secret, settings.xml ConfigMap, and TrustStore ConfigMap to the <username>-devspaces namespace:

   $ oc apply -f tls-cer.yaml -n <username>-devspaces
   $ oc apply -f settings-xml.yaml -n <username>-devspaces
   $ oc apply -f init-truststore.yaml -n <username>-devspaces

   Copy code to clipboard
7. Start a Maven workspace.
8. Open a new terminal in the tools container.
9. Run ~/init-truststore.sh.

Verification

1. In the workspace terminal, verify the Maven mirror configuration:

   $ mvn help:effective-settings

   Copy code to clipboard

   The output includes the mirror URLs from your settings.xml ConfigMap.

2. Build a Maven project to verify artifact resolution from the mirror:

   $ mvn package

   Copy code to clipboard

Procedure

1. Create a Secret to store the TLS certificate:

   kind: Secret
   apiVersion: v1
   metadata:
     name: tls-cer
     annotations:
       controller.devfile.io/mount-path: /home/user/certs
       controller.devfile.io/mount-as: file
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
   data:
     tls.cer: >-
       <Base64_encoded_content_of_public_cert>

   Copy code to clipboard

   where:

   <Base64_encoded_content_of_public_cert>

   The Base64-encoded content of your Gradle artifact repository’s public TLS certificate, with line wrapping disabled.

2. Create a ConfigMap for the TrustStore initialization script:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: init-truststore
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user/
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
   data:
     init-truststore.sh: |
       #!/usr/bin/env bash
   
       keytool -importcert -noprompt -file /home/user/certs/tls.cer -cacerts -storepass changeit

   Copy code to clipboard

3. Create a ConfigMap for the Gradle init script:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: init-gradle
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user/.gradle
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
   data:
     init.gradle: |
       allprojects {
         repositories {
           mavenLocal ()
           maven {
             url "https://<gradle_artifact_repository_route>/repository/maven-public/"
             credentials {
               username "admin"
               password "passwd"
             }
           }
         }
       }

   Copy code to clipboard

   where:

   <gradle_artifact_repository_route>

   The hostname and path of your internal Gradle artifact repository.

4. Apply the Secret and both ConfigMaps to your project:

   $ oc apply -f tls-cer.yaml -n <your_namespace>
   $ oc apply -f init-truststore.yaml -n <your_namespace>
   $ oc apply -f init-gradle.yaml -n <your_namespace>

   Copy code to clipboard
5. Start a Gradle workspace.
6. Open a new terminal in the tools container.
7. Run ~/init-truststore.sh.

Verification

1. In the workspace terminal, build a Gradle project to verify artifact resolution from the mirror:

   $ gradle build

   Copy code to clipboard

Procedure

1. Create a Secret to store the TLS certificate:

   kind: Secret
   apiVersion: v1
   metadata:
     name: tls-cer
     annotations:
       controller.devfile.io/mount-path: /public-certs
       controller.devfile.io/mount-as: file
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
   data:
     nexus.cer: >-
       <Base64_encoded_content_of_public_cert>

   Copy code to clipboard

   where:

   <Base64_encoded_content_of_public_cert>

   The Base64-encoded content of your npm artifact repository’s public TLS certificate, with line wrapping disabled.

2. Apply the Secret to your project:

   $ oc apply -f tls-cer.yaml -n <your_namespace>

   Copy code to clipboard

3. Create a ConfigMap to set the NPM_CONFIG_REGISTRY environment variable:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: disconnected-env
     annotations:
       controller.devfile.io/mount-as: env
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
   data:
     NPM_CONFIG_REGISTRY: >-
       https://<npm_artifact_repository_route>/repository/npm-all/

   Copy code to clipboard

   where:

   <npm_artifact_repository_route>

   The hostname and path of your internal npm artifact repository.

4. Apply the ConfigMap to your project:

   $ oc apply -f disconnected-env.yaml -n <your_namespace>

   Copy code to clipboard
5. Start a npm workspace.

6. Configure the workspace to trust the self-signed certificate by using one of the following options:

   1. Set the NODE_EXTRA_CA_CERTS environment variable to the path of the TLS certificate:

      $ export NODE_EXTRA_CA_CERTS=/public-certs/nexus.cer
      $ npm install

      Copy code to clipboard

   2. Alternatively, disable self-signed certificate validation:

      $ npm config set strict-ssl false

      Copy code to clipboard
      Warning

      Disabling SSL/TLS bypasses the validation of your self-signed certificates. For a more secure solution, use NODE_EXTRA_CA_CERTS (sub-step a).

Verification

1. Open a terminal in your workspace.

2. Verify the npm registry configuration:

   $ npm config get registry

   Copy code to clipboard

   The output shows the artifact repository URL from your ConfigMap.

3. Install a package to verify artifact resolution from the mirror:

   $ npm install express

   Copy code to clipboard

Procedure

1. Create a Secret to store the TLS certificate:

   kind: Secret
   apiVersion: v1
   metadata:
     name: tls-cert
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
     annotations:
       controller.devfile.io/mount-path: /home/user/certs
       controller.devfile.io/mount-as: file
   type: Opaque
   data:
     tls.cer: >-
       <Base64_encoded_TLS_certificate>

   Copy code to clipboard

   where:

   <Base64_encoded_TLS_certificate>

   The Base64-encoded content of your internal PyPI mirror’s TLS certificate.

2. Apply the Secret to your project:

   $ oc apply -f tls-cert.yaml -n <your_namespace>

   Copy code to clipboard

3. Create a ConfigMap with your pip configuration:

   Warning

   Applying a ConfigMap that sets environment variables might cause a workspace boot loop. If you encounter this behavior, remove the ConfigMap and edit the devfile directly.

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: pip-config
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user/.config/pip
   data:
     pip.conf: |
       [global]
       index-url = <your_internal_pypi_url>
       trusted-host = <your_internal_pypi_host>
       cert = /home/user/certs/tls.cer

   Copy code to clipboard

   where:

   <your_internal_pypi_url>

   The URL of your internal PyPI mirror.

   <your_internal_pypi_host>

   The hostname of your internal PyPI mirror.

4. Apply the ConfigMap to your project:

   $ oc apply -f pip-config.yaml -n <your_namespace>

   Copy code to clipboard
5. Start or restart your workspace.

Verification

1. Open a terminal in your workspace.

2. Verify the pip configuration:

   $ pip config list

   Copy code to clipboard

3. Install a package to verify the configuration:

   $ pip install requests

   Copy code to clipboard

Procedure

1. Create a Secret to store the TLS certificate:

   kind: Secret
   apiVersion: v1
   metadata:
     name: tls-cert
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
     annotations:
       controller.devfile.io/mount-path: /home/user/certs
       controller.devfile.io/mount-as: file
   type: Opaque
   data:
     tls.cer: >-
       <Base64_encoded_TLS_certificate>

   Copy code to clipboard

   where:

   <Base64_encoded_TLS_certificate>

   The Base64-encoded content of your Go module proxy’s TLS certificate.

2. Apply the Secret to your project:

   $ oc apply -f tls-cert.yaml -n <your_namespace>

   Copy code to clipboard

3. Create a ConfigMap with Go environment variables:

   Warning

   Applying a ConfigMap that sets environment variables might cause a workspace boot loop. If you encounter this behavior, remove the ConfigMap and edit the devfile directly.

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: go-config
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
     annotations:
       controller.devfile.io/mount-as: env
   data:
     GOPROXY: <your_go_proxy_url>
     GONOSUMDB: "*"
     GOPRIVATE: "<your_private_modules>"
     SSL_CERT_FILE: /home/user/certs/tls.cer

   Copy code to clipboard

   where:

   <your_go_proxy_url>

   The URL of your internal Go module proxy.

   <your_private_modules>

   A comma-separated list of Go module path prefixes for private modules that bypass the proxy and checksum database.

4. Apply the ConfigMap to your project:

   $ oc apply -f go-config.yaml -n <your_namespace>

   Copy code to clipboard
5. Start or restart your workspace.

Verification

1. Open a terminal in your workspace.

2. Verify the Go configuration:

   $ go env GOPROXY

   Copy code to clipboard

3. Download a Go module to verify the configuration:

   $ go get github.com/gin-gonic/gin

   Copy code to clipboard

Procedure

1. Create a Secret to store the TLS certificate:

   kind: Secret
   apiVersion: v1
   metadata:
     name: tls-cer
     annotations:
       controller.devfile.io/mount-path: /home/user/certs
       controller.devfile.io/mount-as: file
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-secret: 'true'
   data:
     tls.cer: >-
       <Base64_encoded_content_of_public_cert>

   Copy code to clipboard

   where:

   <Base64_encoded_content_of_public_cert>

   The Base64-encoded content of your NuGet artifact repository’s public TLS certificate, with line wrapping disabled.

2. Apply the Secret to your project:

   $ oc apply -f tls-cer.yaml -n <your_namespace>

   Copy code to clipboard

3. Create a ConfigMap to set the SSL_CERT_FILE environment variable to the path of the TLS certificate:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: disconnected-env
     annotations:
       controller.devfile.io/mount-as: env
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
   data:
     SSL_CERT_FILE: /home/user/certs/tls.cer

   Copy code to clipboard

4. Create a ConfigMap for the nuget.config file:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: init-nuget
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /projects
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
       controller.devfile.io/watch-configmap: 'true'
   data:
     nuget.config: |
       <?xml version="1.0" encoding="UTF-8"?>
       <configuration>
         <packageSources>
           <add key="nexus2" value="https://<nuget_artifact_repository_route>/repository/nuget-group/"/>
         </packageSources>
         <packageSourceCredentials>
           <nexus2>
               <add key="Username" value="admin" />
               <add key="Password" value="passwd" />
           </nexus2>
         </packageSourceCredentials>
       </configuration>

   Copy code to clipboard

   where:

   <nuget_artifact_repository_route>

   The hostname and path of your internal NuGet artifact repository.

5. Apply both ConfigMaps to your project:

   $ oc apply -f disconnected-env.yaml -n <your_namespace>
   $ oc apply -f init-nuget.yaml -n <your_namespace>

   Copy code to clipboard
6. Start a NuGet workspace.

Verification

1. Open a terminal in your workspace.

2. Verify the NuGet source configuration:

   $ dotnet nuget list source

   Copy code to clipboard

   The output includes the artifact repository URL from your nuget.config ConfigMap.

3. Restore packages to verify artifact resolution from the mirror:

   $ dotnet restore

   Copy code to clipboard

Procedure

1. Add a volume component in the devfile:

   ...
   components:
     ...
     - name: <chosen_volume_name>
       volume:
         size: <requested_volume_size>G
     ...

   Copy code to clipboard

2. Add a volumeMount for the relevant container in the devfile:

   ...
   components:
     - name: ...
       container:
         ...
         volumeMounts:
           - name: <chosen_volume_name_from_previous_step>
             path: <path_where_to_mount_the_PV>
         ...

   Copy code to clipboard

   For example, when a workspace is started with the following devfile, the cache PV is provisioned to the golang container in the /.cache container path:

   schemaVersion: 2.1.0
   metadata:
     name: mydevfile
   components:
     - name: golang
       container:
         image: golang
         memoryLimit: 512Mi
         mountSources: true
         command: ['sleep', 'infinity']
         volumeMounts:
           - name: cache
             path: /.cache
     - name: cache
       volume:
         size: 2Gi

   Copy code to clipboard

Procedure

1. Add the controller.devfile.io/mount-to-devworkspace: true label to the PVC.

   $ oc label persistentvolumeclaim <PVC_name> \
             controller.devfile.io/mount-to-devworkspace=true

   Copy code to clipboard

2. Optional: Use the annotations to configure how the PVC is mounted:

   Table 8.1. Optional annotations

   Annotation	Description
   controller.devfile.io/mount-path:	The mount path for the PVC. Defaults to /tmp/<PVC_name>.
   controller.devfile.io/read-only:	Set to 'true' or 'false' to specify whether the PVC is to be mounted as read-only. Defaults to 'false', resulting in the PVC mounted as read/write.

   For example, to mount a read-only PVC:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: <pvc_name>
     labels:
       controller.devfile.io/mount-to-devworkspace: 'true'
     annotations:
       controller.devfile.io/mount-path: </example/directory>
       controller.devfile.io/read-only: 'true'
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 3Gi
     storageClassName: <storage_class_name>
     volumeMode: Filesystem

   Copy code to clipboard

   where:

   </example/directory>

   The mounted PV is available at this path in the workspace.

   3Gi

   Example size value of the requested storage.

   <storage_class_name>

   The name of the StorageClass required by the claim. Remove this line if you want to use a default StorageClass.

Procedure

1. In the OpenShift Dev Spaces dashboard, click Workspaces.

2. Select the Backups tab to view available backups.

   Figure 9.1. The Backups tab in the Workspace view

   

   The Active tag represents backups for workspaces that still exist in the current cluster. The Deleted tag represents backups for workspaces that no longer exist in the current cluster.

Procedure

1. On the Restore page, select the backup source:

   • Default registry: Select a backup from the list.
   • External registry: Provide a backup image URL.

   Figure 9.2. Restore mode and backup source selection

   
2. Enter a name for the restored workspace.

3. Optional: Configure the memory limits, CPU limits, and the editor.

   Figure 9.3. Resource limits and editor selection

   
4. Click Restore Workspace and wait for the workspace to start.

Procedure

1. List your workspaces:

   $ oc get devworkspaces

   Copy code to clipboard

   Example output:

   NAMESPACE   NAME                 DEVWORKSPACE ID             PHASE     INFO
   user1-dev   spring-petclinic     workspace6d99e9ffb9784491   Running   https://url-to-workspace.com
   user1-dev   golang-example       workspacedf64e4a492cd4701   Stopped   Stopped
   user1-dev   python-hello-world   workspace69c26884bbc141f2   Failed    Container tooling has state CrashLoopBackOff

   Copy code to clipboard

2. Optional: Add the --watch flag to show PHASE changes live:

   $ oc get devworkspaces --watch

   Copy code to clipboard

3. Optional: Add the --all-namespaces flag to list workspaces from all OpenShift Dev Spaces users. This requires administrative permissions on the cluster.

   $ oc get devworkspaces --all-namespaces

   Copy code to clipboard

Procedure

1. Copy the contents of the target Git repository’s devfile to prepare the DevWorkspace custom resource.

   For example:

   components:
     - name: tooling-container
       container:
         image: quay.io/devfile/universal-developer-image:ubi9-latest

   Copy code to clipboard

   For more details, see the Content from devfile.io is not included.devfile v2 documentation.

2. Create a DevWorkspace custom resource, pasting the devfile contents from the previous step under the spec.template field.

   For example:

   kind: DevWorkspace
   apiVersion: workspace.devfile.io/v1alpha2
   metadata:
     name: my-devworkspace
     namespace: user1-dev
   spec:
     routingClass: che
     started: true
     contributions:
       - name: ide
         uri: http://devspaces-dashboard.openshift-devspaces.svc.cluster.local:8080/dashboard/api/editors/devfile?che-editor=che-incubator/che-code/latest
     template:
       projects:
         - name: my-project-name
           git:
             remotes:
               origin: Content from github.com is not included.https://github.com/eclipse-che/che-docs
       components:
         - name: tooling-container
           container:
             image: quay.io/devfile/universal-developer-image:ubi9-latest
             env:
               - name: CHE_DASHBOARD_URL
                 value: https://<openshift_dev_spaces_fqdn>/dashboard/

   Copy code to clipboard

   where:

   name

   Name of the DevWorkspace custom resource. This is the name of the new workspace.

   namespace

   User namespace, which is the target project for the new workspace.

   started

   Determines whether the workspace must be started when the DevWorkspace custom resource is created.

   contributions

   URL reference to the Content from github.com is not included.Microsoft Visual Studio Code - Open Source IDE devfile.

   projects

   Details about the Git repository to clone into the workspace when it starts.

   components

   List of components such as workspace containers and volume components.

   CHE_DASHBOARD_URL

   URL to OpenShift Dev Spaces dashboard.

3. Apply the DevWorkspace custom resource to the cluster.

   $ oc apply -f <devworkspace>.yaml

   Copy code to clipboard

Verification

1. Verify that the workspace is starting by checking the PHASE status of the DevWorkspace.

   $ oc get devworkspaces -n <user_project> --watch

   Copy code to clipboard

   Example output:

   NAMESPACE        NAME                  DEVWORKSPACE ID             PHASE      INFO
   user1-dev        my-devworkspace       workspacedf64e4a492cd4701   Starting   Waiting for workspace deployment

   Copy code to clipboard

2. When the workspace has successfully started, its PHASE status changes to Running in the output of the oc get devworkspaces command.

   Example output:

   NAMESPACE            NAME                  DEVWORKSPACE ID             PHASE      INFO
   user1-dev            my-devworkspace       workspacedf64e4a492cd4701   Running    https://url-to-workspace.com

   Copy code to clipboard

   You can then open the workspace by using one of these options:

   • Visit the URL provided in the INFO section of the output of the oc get devworkspaces command.
   • Open the workspace from the OpenShift Dev Spaces dashboard.

Procedure

1. Run the following command to stop a workspace:

   $ oc patch devworkspace <workspace_name> \
   -p '{"spec":{"started":false}}' \
   --type=merge -n <user_namespace> && \
   oc wait --for=jsonpath='{.status.phase}'=Stopped \
   dw/<workspace_name> -n <user_namespace>

   Copy code to clipboard

Procedure

1. Run the following command to start a stopped workspace:

   $ oc patch devworkspace <workspace_name> \
   -p '{"spec":{"started":true}}' \
   --type=merge -n <user_namespace> && \
   oc wait --for=jsonpath='{.status.phase}'=Running \
   dw/<workspace_name> -n <user_namespace>

   Copy code to clipboard

Procedure

1. Open the OpenShift Dev Spaces dashboard and start a workspace.
2. After the workspace starts, open a terminal in the workspace container.

3. Run oc or kubectl commands to deploy applications, inspect and manage cluster resources, or view logs. The injected OpenShift user token authenticates these commands automatically.

   $ oc get pods

   Copy code to clipboard
   

Procedure

1. Open the Topology view to list all projects.
2. In the Select an Application search field, type workspace to list all workspaces.

3. Click the workspace to edit.

   The deployments are displayed as graphical circles surrounded by circular buttons. One of these buttons is Edit Source Code.

   
4. Click the Edit Source Code button. This redirects to a workspace with the cloned source code of the application component.

Procedure

1. Open the Red Hat Applications menu by using the three-by-three matrix icon in the upper right corner of the main screen.

   The drop-down menu displays the available applications.

   
2. Click the OpenShift Dev Spaces link to open the Red Hat OpenShift Dev Spaces Dashboard.

Procedure

1. Open the OpenShift Dev Spaces dashboard and click the three-by-three matrix icon in the upper right corner of the main screen.

   The drop-down menu displays the available applications.

   
2. Click the OpenShift console link to open the OpenShift web console.

Procedure

1. Verify that the browser supports WebSocket connections by opening the browser developer tools (F12), navigating to the Console tab, and running:

   var ws = new WebSocket('wss://echo.websocket.org');
   ws.onopen = function() { console.log('WebSocket OK'); ws.close(); };
   ws.onerror = function() { console.log('WebSocket FAILED'); };

   Copy code to clipboard

   If the output is WebSocket FAILED, WebSocket connections are blocked. Contact your network administrator to allow WSS connections on port 443.

2. Verify that firewall rules allow WebSocket Secure (WSS) connections on port 443 to the OpenShift Dev Spaces hostname.
3. If your network uses a proxy server, verify that the proxy allows WebSocket upgrade requests. Some proxies block HTTP upgrade headers by default.

4. Verify DNS resolution from a workspace terminal:

   nslookup <devspaces_hostname>

   Copy code to clipboard

   If the DNS lookup fails, the workspace Pod cannot resolve the OpenShift Dev Spaces hostname. Verify the cluster DNS configuration and any custom DNS settings in the workspace namespace.

5. If you encounter x509: certificate signed by unknown authority errors when connecting to an HTTPS endpoint from inside a workspace, the workspace does not trust the TLS certificate.

   Contact your administrator to import the required Certificate Authority (CA) certificates.