User guide

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>

   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:

     Expand

     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

     Show more

     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.

     Expand

     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

     Show more
     Expand

     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

     Show more
     Expand

     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>

     Show more

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>

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

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

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

   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

Verification

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

   $ stat /dev/fuse

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"

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>

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 kubedock server source. Alternatively, you can use the following command to view the available options:

   # kubedock server --help

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

Procedure

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

   export DOCKER_HOST=tcp://127.0.0.1:2475

2. Start the Kubedock server in the background:

   kubedock server --port-forward &

3. Use standard Docker commands that Kubedock handles:

   docker run --rm hello-world

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

   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 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]

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, then click Open Gateway to connect to your OpenShift Dev Spaces workspace:

   

3. Provide or select the OpenShift Application Programming Interface (API) server URL, choose an authentication method, provide the required authentication details, and click OK:

   

Procedure

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

   

2. Provide or select the OpenShift Application Programming Interface (API) server URL, choose an authentication method, then provide the required authentication details and click the Check connection button to continue:

   

3. Choose your workspace, ensure that it is running, then click the Connect button:

   

Procedure

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

   

   For OpenShift Dev Spaces Toolbox plugin version 0.0.1:

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

   For OpenShift Dev Spaces Toolbox plugin version 0.0.2 and later:

   The plugin handles port forwarding automatically.

2. 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:

   

   For OpenShift Dev Spaces Toolbox plugin version 0.0.2 and later:

   To connect directly from the Toolbox App without using the Dashboard, open the Environment actions menu and click the Connect button:

   

3. After the connection is established, click the workspace name. On the Tools tab, choose an IDE to install in your workspace:

   

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

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>"
       ]
     }

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.

Procedure

1. Install version 0.36.2 of the Dev Spaces Copilot Chat Integration extension.

   Choose one of the following options depending on your Open VSX registry configuration:

   • If your OpenShift Dev Spaces instance is configured to use the public Open VSX registry or a standalone Open VSX registry that contains the extension:

     Open the Extensions view by pressing Ctrl+Shift+X, search for Dev Spaces Copilot Chat Integration, select version 0.36.2, and click Install.

   • If your OpenShift Dev Spaces instance uses the default embedded Open VSX registry or a registry that does not contain the extension, install it manually from a .vsix file:

     Download the .vsix file from the Open VSX registry, then press F1 to open the Command Palette and run Extensions: Install from VSIX…​.

   Important

   Use version 0.36.2 of the extension. Other versions may not be compatible with the current OpenShift Dev Spaces editor.

2. Authenticate using Device Authentication.

   Press F1 to open the Command Palette, type GitHub: Device Authentication, and select the command.

   Important

   Complete Device Authentication before attempting to use AI features. Initiating "Sign in to use AI Features" without a valid device authentication token causes authentication errors that require signing out and re-authenticating.

3. Complete the device authentication flow.

   A notification appears with a device code. Click the link to open the GitHub device activation page in your browser, paste the code, and authorize access.

4. Refresh the browser page.

   After successful authentication, a notification prompts you to refresh the browser page. Refresh the page to apply the authentication token. Copilot Chat is authenticated automatically and ready to use.

1. Click the Accounts icon on the left activity bar, select your account, and click Sign Out. A confirmation dialog appears. Click Sign Out to confirm.
2. Press F1 to open the Command Palette and run GitHub: Device Authentication. Complete the device authentication flow in the browser.
3. Refresh the browser page when prompted. Copilot Chat is now ready to use.

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>

   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>

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

   Expand

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

   Show more

   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

   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>

   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>

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

Procedure

1. Encode the .dockercfg file to Base64:

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

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

3. Apply the Secret:

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

Procedure

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

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

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

3. Apply the Secret:

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

Procedure

1. Go to https://<openshift_dev_spaces_fqdn>/api/user/id in the web browser to get your OpenShift Dev Spaces user ID.

2. Create a Kubernetes Secret with your access token:

   kind: Secret
   apiVersion: v1
   metadata:
     name: personal-access-token-<git_provider>
     labels:
       app.kubernetes.io/component: scm-personal-access-token
       app.kubernetes.io/part-of: che.eclipse.org
     annotations:
       che.eclipse.org/che-userid: <devspaces_user_id>
       che.eclipse.org/scm-personal-access-token-name: <git_provider_name>
       che.eclipse.org/scm-url: <git_provider_endpoint>
       che.eclipse.org/scm-organization: <git_provider_organization>
   type: Opaque
   stringData:
     token: <your_personal_access_token>

   where:

   che.eclipse.org/che-userid

   Your OpenShift Dev Spaces user ID.

   che.eclipse.org/scm-personal-access-token-name

   The Git provider name (github, gitlab, bitbucket-server, or azure-devops).

   che.eclipse.org/scm-url

   The Git provider URL endpoint (e.g., https://github.com, https://gitlab.com).

   che.eclipse.org/scm-organization

   Required only for Azure DevOps: your Git provider user organization, or collection if Azure DevOps Server is used.

   token

   Your personal access token.

   Example for GitHub:

   kind: Secret
   apiVersion: v1
   metadata:
     name: personal-access-token-github
     labels:
       app.kubernetes.io/component: scm-personal-access-token
       app.kubernetes.io/part-of: che.eclipse.org
     annotations:
       che.eclipse.org/che-userid: 1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p
       che.eclipse.org/scm-personal-access-token-name: github
       che.eclipse.org/scm-url: https://github.com
   type: Opaque
   stringData:
     token: ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

3. Visit https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace to get your OpenShift Dev Spaces user namespace as name.

4. Apply the Secret to your OpenShift Dev Spaces user project:

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

   Important

   If you are using Azure DevOps Server, you must also modify the workspace’s gitconfig with the following section:

   extraheader = "Authorization: Basic <base64-encoded(:personal-access-token)>"

   To generate the key-value pair, use the following command:

   echo -n "extraheader = \"Authorization: Basic "$(printf ":%s" <personal access token> | base64)\"

   The extraheader configuration is needed for remote git operations to Azure DevOps Server, for example git clone. This authorization method has a higher priority over the git credentials store, and as a result, remote operations to other Git providers will fail.

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

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
       }

   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>

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

   Expand

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

   Show more

   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"

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

2. Apply the ConfigMap to your project:

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

3. Start or restart your workspace.

Verification

1. Open a terminal in your workspace.

2. Verify the Git configuration:

   $ git config --list

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>

   where:

   <your_namespace>

   Your project name. To find your project, go to 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

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>

   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

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>

   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

   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

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

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

   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

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>

   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

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"
             }
           }
         }
       }

   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>

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

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>

   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>

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/

   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>

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

   2. Alternatively, disable self-signed certificate validation:

      $ npm config set strict-ssl false

      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

   The output shows the artifact repository URL from your ConfigMap.

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

   $ npm install express

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>

   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>

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

   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>

5. Start or restart your workspace.

Verification

1. Open a terminal in your workspace.

2. Verify the pip configuration:

   $ pip config list

3. Install a package to verify the configuration:

   $ pip install requests

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>

   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>

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

   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>

5. Start or restart your workspace.

Verification

1. Open a terminal in your workspace.

2. Verify the Go configuration:

   $ go env GOPROXY

3. Download a Go module to verify the configuration:

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

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>

   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>

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

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>

   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>

6. Start a NuGet workspace.

Verification

1. Open a terminal in your workspace.

2. Verify the NuGet source configuration:

   $ dotnet nuget list source

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

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

   $ dotnet restore

Procedure

1. Add a volume component in the devfile:

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

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

   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

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

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

   Expand

   Table 9.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.

   Show more

   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

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

   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

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

   $ oc get devworkspaces --watch

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

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

   For more details, see the 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: 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/

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

Verification

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

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

   Example output:

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

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

   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>

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>

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

   

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'); };

   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>

   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.