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

CodeReady Workspaces 2.2 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.2 is available from the OperatorHub in OpenShift 4.3 and beyond. CodeReady Workspaces 2.2 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.3 or later, get CodeReady Workspaces from the OperatorHub and follow the Installing CodeReady Workspaces on OpenShift 4 from OperatorHub chapter of the Installation Guide.

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 Edit source code icon does not work properly from Developer Topology Perspective.

After the an CodeReady Workspaces application deploys, the topology view should display a clickable icon that loads a CodeReady Workspaces workspace using the devfile that is in the source repository. Instead, it displays the GitHub icon that brings the user to the GitHub source code repository.

When installing CRW on a cluster configured with an authenticated proxy, the installation fails because the CodeReady Workspaces server cannot contact the RH-SSO OIDC endpoint.

On OpenShift 4.4, the catalog bundle image is corrupted and does not appear in OperatorHub. To workaround this issue, update to OpenShift 4.5.

Installation of CodeReady Workspaces with OpenShift OAuth using crwctl in operator mode in some cases fails or does not deploy resources if existing resources from another crwctl 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.

When CodeReady Workspaces deployed on OpenShift 3.11 encounters a certificate error, the error notification links to the wrong remediation instructions.

To import the certificates, see: Installing Codeready Workspaces in TLS mode with self-signed certificates

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

Tasks terminated with the Terminate Task IDE function do not end properly. As a consequence, reactivating the task returns an `The task is already running active` error with the option to use the Restart task function. However, using this function causes a port conflict and the task fails.

Some devfiles are provided as Technology Preview and are not guaranteed to work for all implementations.

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

To work around this issue:

The crwctl workspace:inject command causes the following error during the workspace Pod localization in workspaces created with OpenShift OAuth support.

$ crwctl workspace:inject -n codeready-tls-oauth -k
  ✔ Verify if namespace codeready-tls-oauth exists
  ✖ Verify if the workspaces is running
    → No workspace pod is found
    Injecting configurations
 ›   Error: No workspace pod is found

To work around the issue, use the oc login command inside the affected container instead.

When a workspace is created in a dedicated namespace and the namespace is later entirely deleted, the corresponding OpenShift project currently does not get deleted.

To complete the deletion process, delete the project manually from the OpenShift console:

$ oc delete project <projectname>

After using the crwctl server:delete command, the OpenShift project hosted the CodeReady Workspaces instance remains. This makes it impossible to install a new CodeReady Workspaces instance into the still existing default namespace.

To uninstall CodeReady Workspaces completely, remove the namespace manually:

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

To work around the issue:

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.

Instead of removing checluster from the current CodeReady Workspaces project, the checluster is deleted from all projects in the OpenShift Container Platform cluster.

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.

By default, the OpenShift Connector plug-in logs in to the cluster as inClusterUser, which in some cases does not have the manage project permission. This causes an error message to be displayed when creating a new project using OpenShift Application Explorer:

Failed to create Project with error 'Error: Command failed: "/tmp/vscode-unpacked/redhat.vscode-openshift -connector.latest.qvkozqtkba.openshift-connector-0.1.4-523.vsix/extension/out/tools/linux/odo" project create test-project ✗ projectrequests.project.openshift.io is forbidden

To work around this issue, log out from the local cluster and relog in to OpenShift cluster using the OpenShift user’s credentials.

When launching an embedded application of the java-eap-maven stack in the debug mode, the launch often fails. The dialog window with the application URL is already displayed, but the terminal output states that the application is still starting. Using the URL link displayed causes an error.

To work around this issue, update the Go language server plug-in to the latest version.

The subPath in VolumeMount property, necessary for mounting secrets, is supported on Kubernetes version 1.15, where OpenShift 3.11 is based on Kubernetes version 1.11. As a consequence, mounting a Kubernetes secret into a workspace container does not work.

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.

The crwctl server:stop command is unable to shut down the CodeReady Workspaces server and instead fails with a timeout and displays the following error message:

›   Error: E_SHUTDOWN_CHE_SERVER_FAIL - Failed to shutdown CodeReady Workspaces server. E_CHE_API_NO_RESPONSE - Endpoint: http://codeready-ndp-test.apps.crw.codereadyqe.com/api/system/stop?shutdown=true - Error message: timeout of
 ›   3000ms exceeded

To work around the issue, execute crwctl server:stop again.