Chapter 1. Release notes

Red Hat CodeReady Workspaces is a web-based integrated development environment (IDE). CodeReady Workspaces runs in OpenShift and is well-suited for container-based development.

This section documents the most important features and bug fixes in Red Hat CodeReady Workspaces. For the list of CodeReady Workspaces 2.1 release issues, see the Chapter 2, Known issues section.

CodeReady Workspaces 2.1.1 with several bugfixes has been released. To upgrade, follow the instructions in the Upgrading CodeReady Workspaces chapter of the Installation Guide.

TLS (https) now enabled by default; adjust old CodeReady Workspaces instance manually

  • In CodeReady Workspaces 2.0, the tlsSupport parameter was set to false by default, allowing the use of insecure HTTP. In CodeReady Workspaces 2.1, secure HTTPS is required to use the most recent Theia IDE, and is therefore enabled by default.

    Existing workspaces from 2.0 need to be adjusted to use tlsSupport: true: 

    $ oc patch -n <codereadyNamespace> checluster/codeready-workspaces \
  --patch "{\"spec\":{\"server\":{\"tlsSupport\": true}}}" --type=merge
    Note

    This issue is fixed by updating to CodeReady Workspaces version 2.1.1.

1.1. About Red Hat CodeReady Workspaces

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

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

  • Support for OpenShift Dedicated 4.3

    Using the CodeReady Workspaces Operator and crwctl, CodeReady Workspaces can be installed on OpenShift Dedicated versions 3.11 and 4.3. Users can then benefit from all Red Hat-managed container application platform features, including:

  • New onboarding flow from the dashboard

    The Getting Started with CodeReady Workspaces page lets users start workspaces by clicking a single button and without having to configure anything. Users see the Getting Started page by default when there is no workspace created.

  • Temporary storage options for workspace creation

    The dashboard propose options to enable or disable the temporary storage and displays the kubernetes namespace used when creating a workspace.

  • Quarkus implementation

    Quarkus support for workspaces is now available. By default, the create, read, update, and delete (CRUD) services are provided. The workspace contains ready-to-use commands to start developer mode, including debugging capabilities.

    The workspace also contains the Red Hat VS Code Quarkus plug-in to generate a new project or provide snippets using the Command palette.

  • CodeReady Workspaces Air Gap with OpenShift 4.3

    On OpenShift 4.3, it is now possible to follow Configuring OperatorHub for restricted networks using OpenShift Container Platform and configure the CodeReady Workspaces Operator to be used this way.

  • Languages updates

    Provided versions:

    • .NET 3.1 - Update from version 2.1
    • Java 11 - Extending the current use of Java 8

  • Support added

    • Apache Camel K, a lightweight integration framework for serverless and microservice architectures.
    • Gradle, a build automation tool, often used for JVM languages such as Java, Groovy, or Scala.

  • New chapters in the documentation

    • Using artifact repositories in a restricted environment
    • Backup and Disaster Recovery
    • Configuring system properties for CodeReady Workspaces
    • OpenShift Connector, the VS Code extension

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

From OpenShift 4.1, CodeReady Workspaces 2.1 is available from the OperatorHub. Based on a new Operator that uses the Operator Lifecycle Manager, the installation flow is simpler and can be handled without leaving the OpenShift Console.​

For OpenShift 4.3, get CodeReady Workspaces from the OperatorHub and follow the Installing CodeReady Workspaces on OpenShift 4 from OperatorHub chapter of the Installation Guide.

1.2. Notable enhancements

1.2.1. Support of self-signed certificates and SSH key pairs, Git flow improvements

  • git clone command is now supported for repositories with self-signed SSL certificates, allowing customers behind a firewall (air gap) to connect to company internal Git repositories and clone from them.
  • SSH key upload in CodeReady Workspaces using the command palette is now allowed. Users are now able to configure Git credentials while doing a commit without those parameters already set.
  • The user’s SSH keys are mounted automatically on workspace start into a single Kubernetes secret.
  • Users can list their SSH keys using the SSH: view public key command and check if the public part is uploaded to the Git server by performing a private remote Git operation, such as git clone or git push.

1.2.2. Devfile

  • Monaco is now the main devfile editor, replacing Codemirror. This provides YAML highlighting and validation, which makes it easier to customize devfiles manually. The Che devfile editor now supports auto-completion, validation, and hover.
  • Added the ability to create a workspace from the dashboard with a devfile.
  • A preview URL is now offered when a task is started, and support for such URLs is added to devfiles.
  • Environment variables for plug-ins, editors, and other OpenShift or Kubernetes components are supported. This allows plug-in developers to set default values that are usable in most cases and can be overwritten later in a devfile if needed.
  • Adds the ability for CodeReady Workspaces factories to override devfile properties.
  • Adds the ability for the devfile to be set to the current project opened in CodeReady Workspaces by default, if not specified in the project section of the devfile. Also, launching a workspace using the factory stored within a Git repository or a Git branch leads to project creation. The project name then matches the name of the repository or the branch.
  • Adds the ability for the CodeReady Workspaces factory loader to read a devfile from a GitHub repository URL that ends in .git.

1.2.3. Other enhancements

1.2.3.1. Termination of a running task from the IDE

Adds the ability to stop a running task by sending Ctrl+c to the corresponding terminal or by using the Command palette → Terminate Task action.

1.2.3.2. Access to the workspace container logs is now persistent

All of the workspace lifetime logs are now persistent and accessible to the end-user using the crwctl and dashboard.

1.2.3.3. The URL in the preview panel is now editable

The preview panel text-field that displays the currently opened URL is now editable and allows the user to navigate to the different components of an application, such as endpoints and pages.

1.2.3.4. Monitoring and Tracing for multiple Threads pools of CodeReady Workspaces server

Users can now monitor and trace multiple thread pools of CodeReady Workspaces server, the proper adjustment of which can lead to better handling of workspace start load.

1.2.3.5. Opening terminal in a specific container

The command pallet offers actions related to specific containers.

1.2.3.6. Offline devfile creation

Air gap mode allows offline devfile registry to include sample projects and images.

1.2.3.7. Operators use a digest for containerImage reference instead of a tag

In CodeReady Workspaces, registries and Operator metadata now use specific SHA256 image digests instead of mutable image tags like :2.0. This provides a number of benefits, including better security and support for the new approach to restricted environments in Openshift 4.3. A complete list of images that the Operator could use, including all the stack and sidecar images, is now included in the relatedImages section of the Operator metadata clusterserviceversion (CSV) YAML file.

1.2.3.8. Plug-in broker refactoring

The plug-in installation process was split into separate phases to reduce the time needed to process plug-ins and to enable plug-ins to be cached between workspace launches.

1.2.3.9. Ability to add a plug-in via a URL that is not in a plug-in registry

Improvements in the plug-in broker and plug-in resolution code allow adding a set of default plug-ins, without including them in the plug-in registry. Users can configure the CodeReady Workspaces server with a list of URLs to plug-in meta.yaml files.

1.2.3.10. CodeReady Workspaces command line tool (crwctl) improvements

  • User can use the watch utility to monitor a newly created Pod.
  • The crwctl inject command is now supported in OpenShift command line interface (CLI).

1.2.3.11. Added codeready-workspaces command syntax auto-completion to the Task editor

Added support for CRW specific autocompletion and hinting when editing tasks in a CRW workspace. The editor now includes CRW-specific fields. For example, which container to use, and assisting the user while adding a task to Che-Theia.

1.2.3.12. Workspaces are created in a namespace based on the username value

In CRW 2.0, workspaces were created in a dedicated namespace named with the workspace ID by default.

Starting with CRW 2.1, by default, all workspaces of a given user are created in a single namespace named <username>-crw.

1.2.3.13. Internal editor improvements

  • File tree empty-space reduction
  • VS Code API compatibility extension
  • More plug-ins supported

1.3. Supported platforms

1.3.1. Supported platforms and installation methods

The following section provides information about the availability of CodeReady Workspaces 2.1 on OpenShift Container Platform, OpenShift Dedicated, and about their supported installation methods.

Red Hat CodeReady Workspaces can be installed on OpenShift Container Platform and OpenShift Dedicated starting at version 3.11.

Table 1.1. Availability of CodeReady Workspaces 2.1 on OpenShift Container Platform and OpenShift Dedicated

 

3.11

4.3

4.4

4.5

OpenShift Container Platform

✔

✔

✔

Technical Preview

OpenShift Dedicated

✔

✔

Technical Preview

Technical Preview

Table 1.2. Supported installation method for CodeReady Workspaces 2.1 on OpenShift Container Platform and OpenShift Dedicated

 

3.11

4.3

4.4

OpenShift Container Platform

crwctl

OperatorHub

OperatorHub

OpenShift Dedicated

crwctl

OperatorHub

N/A

It is possible to use the crwctl utility script for deploying CodeReady Workspaces 2.1 on OpenShift Container Platform versions 4.3, 4.4, and OpenShift Dedicated version 4.3. This method is considered unofficial and serves as a backup installation method for situations where the installation method using OperatorHub is not available.

1.3.2. Installing and deploying CodeReady Workspaces

For OpenShift 3.11, see the Installing CodeReady Workspaces chapter of the Administrator Guide.

For OpenShift 4.4, see the Installing CodeReady Workspaces from Operator Hub chapter of the Installation Guide.

1.3.3. Support policy

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

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

1.4. Difference between Eclipse Che and Red Hat CodeReady Workspaces

The main difference between CodeReady Workspaces and Eclipse Che is that CodeReady Workspaces is supported by Red Hat. There is no difference in the technologies these two products use. Nevertheless, CodeReady Workspaces runs the plug-ins and devfiles from supported images. Licensing, packaging, and support are also provided by Red Hat.

The following table lists the differences between Eclipse Che and Red Hat CodeReady Workspaces:

CodeReady WorkspacesEclipse Che

The CodeReady Workspaces stacks are based on Red Hat Enterprise Linux. The CodeReady Workspaces stacks list includes several stack images based on Red Hat Enterprise Application Platform, such as Vert.x, Springboot, etc.

The Eclipse Che stacks are based on CentOS and other free operating systems