Red Hat CodeReady Workspaces 2.4 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.18.2 and offers a number of enhancements and new features, including:

CodeReady Workspaces 2.4 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 chapter of the Installation Guide.

CodeReady Workspaces 2.4 is available from the OperatorHub in OpenShift 4.4 and beyond. CodeReady Workspaces 2.4 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.4 on OpenShift Container Platform and OpenShift Dedicated.

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

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

CodeReady Workspaces 2.4 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.

The Go language plug-in moved from the v3/plugins/ms-vscode/ directory to v3/plugins/golang directory in the plug-in registry. As a result, the older workspaces created from the Go devfile cannot migrate to the current release version.

To resolve this issue:

Following the steps in Using Operator Lifecycle Manager on restricted networks chapter in OpenShift docummentation, leads to an issue when ubi8-minimal image is not present in the mappings.txt and imageContentSourcePolicy.yaml files, causing an installation in a disconnected environment to fail.

To work around this issue:

CodeReady Workspaces2.4 instances does not support a debug session for workspaces created from a Python devfile.

All Camel K specific commands and Camel K Integration explorer are not working out of the box.

To work around this issue:

CodeReady Workspaces requires a new sub-domain for every workspace it manages. This can lead to an inefficient situation when CodeReady Workspaces manages a large number of workspaces, while managing a conventional certificate for each of these workspaces. Administrators can try to work around this by setting a wildcard TLS certificate to secure all OpenShift routes of dedicated workspaces.

In case it is not possible to enable wildcard certificates globally on the OpenShift router, use a dedicated router for CodeReady Workspaces workspaces and Ingress Controller sharding. See Configuring Ingress Controller sharding by using route labels

routeSelector:
   matchExpressions:
      key: che.workspace_id
      operator: Exists

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 step 6 of the Installing CodeReady Workspaces on OpenShift 3 using the Operator Installation Guide chapter.

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

Workspaces created from the PHP-DI devfile incorrectly highlight valid code as erroroneous.

To work around this issue:

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.

If the <username>-che namespace strategy is used, a problem can occur with the user names that contain characters incompatible with the Kubernetes namespace name pattern.

The specified namespace example@redhat.com-codeready is invalid: a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name', or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')

To work around this issue, do one of the following:

For best performance, Red Hat recommends using block storage for Persistent Volumes used with CodeReady Workspaces. The use of NFS is not recommended.

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.

CodeReady Workspaces workspaces created on IBM Z and OpenShift 4.4 in PSI, fail to terminate the Java tasks using openJ9.

To end a stuck process or unterminated running task, reload the browser tab to reconnect the workspace.

If the issue is still present, restart the workspace for changes to take effect.