Release notes and known issues

OpenShift Dev Spaces runs on OpenShift 4.12–4.17 on the following CPU architectures:

The following CPU architecture requires Openshift 4.13-4.17 to run OpenShift Dev Spaces:

For Red Hat OpenShift Dev Spaces 3.17, Red Hat will provide support for deployment, configuration, and use of the product.

There are some differences between Red Hat OpenShift Dev Spaces and the upstream project on which it is based, Eclipse Che:

Red Hat provides licensing and packaging to ensure enterprise-level support for OpenShift Dev Spaces.

With this release, you can specify a passphrase while adding a new SSH key using the "SSH Keys" tab in the User Preferences.

This feature is a Technology Preview feature, and disabled by default. In order to use this feature, config.enableExperimentalFeatures: true must be set in the DevWorkspaceOperatorConfig Custom Resource.

With this release, you can restrict the total number of the 'Running' workspaces on a cluster using the maxNumberOfRunningWorkspacesPerCluster CheCluster CR property.

Learn more about this feature in the official documentation.

With this release, you can specify the list of URLs based on which Cloud Development Environments (CDEs) can be initialized using the dedicated optional allowedSources CheCluster CR property:

     "devEnvironments": {
       "allowedSources": {
         "urls": ["url_1", "url_2"]
       }

     "devEnvironments": {
       "allowedSources": {
         "urls": ["url_1", "url_2"]
       }

Learn more about this feature in the official documentation.

With this release, you can deploy operands managed by the operator (dashboard, gateway, plugin-registry etc.) on the specific cluster nodes using the dedicated nodeSelector and tolerations properties CR properties:

  dashboard:
      deployment:
        nodeSelector:
        tolerations:

  dashboard:
      deployment:
        nodeSelector:
        tolerations:

With this release, you can conceal editor definitions. This is useful when an admin wants to hide particular editor(s) from the Dashboard UI, e.g. remove the IntelliJ and have only Visual Studio Code - Open Source visible.

Learn more about the procedure in the official documentation.

With this release, you can provide endpoint annotations in the devfile. For example, the following devfile snippet will create an ingress or route with the annotation foo: bar on Cloud Development Environment (CDE) startup:

components:
  - container:
      endpoints:
        - name: my-endpoint
          annotation:
            foo: bar
            ...

components:
  - container:
      endpoints:
        - name: my-endpoint
          annotation:
            foo: bar
            ...

The spec.devEnvironments.runtimeClassName property has been added to the CheCluster CR. This property sets the spec.runtimeClassName for all Cloud Development Environment (CDE) pods. The controller.devfile.io/runtime-class attribute for the CDE has precedence over the CheCluster spec.devEnvironments.runtimeClassName property.

With the release, the FailedScheduling event is the default value for the spec.devEnvironments.ignoredUnrecoverableEvents property. This is beneficial when the cluster has an autoscaler configured. If a Cloud Development Environment (CDE) pod cannot be scheduled on any node causing a FailedScheduling event, the CDE startup will be retried when the new node is provisioned.

Before this release, the error message from the previous start would sometimes be shown after the Cloud Development Environment (CDE) restart which was confusing for the user.

The defect has been fixed in this release.

Before this release, installing the latest Python extension (v2024.14.0) would fail with the following error message: "Extension 'ms-python.python' CANNOT use API proposal: terminalShellIntegration". With this release, the issue is fixed

Before this release, starting a workspace with a devfile from an internally hosted Gitlab repository resulted in a "devfile not found" error message. With this release, the defect has been fixed.

Previously, pasting SSH keys from the User Preferences page in the Che Dashboard caused an invalid format error when cloning a git repository. This issue has been fixed in this release.

When a persistent volume mount had a mount path of /home/user/.local, podman was missing in the CDE’s Universal Developer Image (UDI) container. This bug has been fixed in the latest UDI version.

Before this release, if GitHub OAuth was configured and GitHub was down, you could not start existing CDEs from this source. The defect has been fixed in this release and existing CDE will be started even if the OAuth provider is down with a dedicated warning message shown during start.

Previously there was a known issue affecting workspaces using Microsoft Azure DevOps, Bitbucket or GitHub providers in connection with the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN property. Every time you started a workspace, a new personal access token (PAT) was added and the previous one was not removed. When there were more than five existing PATs, you were not able to run the workspace, and the Dashboard was not available. The defect has been fixed in this release.

In the Visual Studio Code - Open Source ("Code - OSS") editor, clicking on links within welcome pages and project README files had no effect. This defect has been fixed in this release.

With this release, Intelij IDEA Community is deprecated.

There is a known issue affecting repositories without a devfile.yaml file. If you start a new workspace from a branch of such repository, the default branch (e.g. 'main') is used for project cloning instead of the expected branch.

There is a known issue when experimental refresh token mode is applied using the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN property for the GitHub and Microsoft Azure DevOps OAuth providers. This causes the workspace starts to reload the dashboard cyclically, creating a new personal access token on each page restart. The refresh token mode works correctly for 'GitLab' and 'BitBucket' OAuth providers.

There’s a known issue with FIPS compliance that results in certain cryptographic modules not being FIPS-validated. Below is a list of requirements and limitations for using FIPS with OpenShift Dev Spaces:

Once the cluster is up and running, install OpenShift Dev Spaces 3.7.1 (3.7-264) and verify that the latest DevWorkspace operator bundle 0.21.2 (0.21-7) or newer is also installed and updated. See https://catalog.redhat.com/software/containers/devworkspace/devworkspace-operator-bundle/60ec9f48744684587e2186a3

The resulting binaries can be scanned and should pass without error.

As they are not related to cryptography, they do not affect FIPS compliance.

Currently, the debugger in Microsoft Visual Studio Code - Open Source does not work in the .NET sample.