Release Notes and Known Issues

Red Hat CodeReady Workspaces 2.5 provides an enterprise-level cloud developer workspace server and browser-based IDE. CodeReady Workspaces includes ready-to-use developer stacks for some of the most popular programming languages, frameworks, and Red Hat technologies.

This minor release of Red Hat CodeReady Workspaces is based on Eclipse Che 7.20.1 and offers a number of enhancements and new features, including:

CodeReady Workspaces 2.5 is available in the Red Hat Container Catalog. Install it on OpenShift Container Platform, starting at version 3.11, by following the instructions in the Installing CodeReady Workspaces on OpenShift Container Platform 3.11 chapter of the Installation Guide.

CodeReady Workspaces 2.5 is available from the OperatorHub in OpenShift 4.4 and beyond. CodeReady Workspaces 2.5 is based on a new Operator that uses the Operator Lifecycle Manager. This makes the CodeReady Workspaces installation flow simpler and doable without leaving the OpenShift Console.​

To install CodeReady Workspaces for OpenShift 4.4 or later, get CodeReady Workspaces from the OperatorHub and follow the Installing CodeReady Workspaces on OpenShift 4 from OperatorHub chapter of the Installation Guide.

This section describes the availability and the supported installation methods of CodeReady Workspaces 2.5 on OpenShift Container Platform.

The minimal OpenShift Container Platform version supporting Red Hat CodeReady Workspaces is OpenShift Container Platform 3.11.

For Red Hat CodeReady Workspaces 2.5, Red Hat will provide support for deployment, configuration, and use of the product.

CodeReady Workspaces 2.5 has been tested on Chrome version 83.0.4103.97 (Official Build) (64-bit).

For more information, see CodeReady Workspaces life-cycle and support policy.

The main differences between CodeReady Workspaces and Eclipse Che are:

Red Hat also provides licensing, packaging, and support, so CodeReady Workspaces is considered a more stable product than the upstream Eclipse Che project.

Instead of suggesting '/projects/' as the default target folder of the Quarkus sample project, the Create Quarkus project button of the Quarkus wizard suggests the root folder (/) instead, which is not visible from the IDE.

To work around this issue, reject the suggested destination and use /projects.

CodeReady Workspaces 2.4 Java JBoss Fuse workspaces deployed on OpenShift with enabled OpenShift OAuth support fail to start after updating to 2.5.

After opening php-di/console.php file in a workspace build using the PHP-DI default YAML file, the predefined command for installing dependencies fails to run.

Workspaces of the CodeReady Workspaces deployed in Single-host mode fail to load the welcome page, displaying the following error message:

Cannot GET /serverj4587ysj-jwtproxy/server-4402/webview/index.html.

CodeReady Workspaces 2.5 instances do not support running a debug session for workspaces created from a Python devfile.

To work around this issue, refresh the page by pressing F5 or Comd+r if using macOS.

Installation of CodeReady Workspaces, using the crwctl server:start with OpenShift OAuth, fails or does not deploy resources if existing resources from another crwctl installation exist in the cluster.

To workaround this issue, delete old resources and perform a fresh installation. For instructions, see Installing CodeReady Workspaces on OpenShift Container Platform 3.11.

Having multiple CodeReady Workspaces deployments on the same cluster is not recommended, and the ability to do so may be removed in a future release.

Some of the sample projects included in the Getting Started devfiles are not designed for offline or airgapped use, so some commands may not work. To resolve this, user may have to talk to a organization’s administrator to get access to internal mirrors, such as NMP, Maven, and PIP.

The base functions of the Getting started ZIP-archived samples embedded in the offline devfile registry do not work.

Commands that require internet access to run: Run, Simple build `, `Outline

The File > Share IDE command currently launches the Workspace tab, but the Share tab is missing.

The crwctl server:delete command removes certain cluster-scoped objects, which causes all other CodeReady Workspaces deployments to terminate unexpectedly.

To work around the issue, patch the Custom Resource Definition:

$ oc patch customresourcedefinition/checlusters.org.eclipse.che -p \
'{ "metadata": { "finalizers": null }}' --type merge

Having multiple CodeReady Workspaces deployments on the same cluster is not recommended, and the ability to do so may be removed in a future release.

Uninstalling the CodeReady Workspaces manually by deleting the checluster custom resource in the OperatorHub causes errors in the CodeReady Workspaces Operator. As a consequence, attempting to re-install CodeReady Workspaces in OperatorHub fails.

In CodeReady Workspaces 2.1 and later, secure HTTPS is required to use the most recent Theia IDE, and therefore TLS mode is enabled by default. Disabling the TLS support will cause user experience to suffer and some UI will not work as expected or at all.

For example, the welcome page may be blank or broken, images may be missing, and other functionality may not work properly.

Support for deploying CodeReady Workspaces on OpenShift Container Platform on IBM Z is currently only available as a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For details about the level of support for Technology Preview features, see Technology Preview Features Support Scope.

Support for deploying CodeReady Workspaces on OpenShift Container Platform on IBM Power Systems is currently only available as a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For details about the level of support for Technology Preview features, see Technology Preview Features Support Scope.