Chapter 2. Notable enhancements

2.1. Initial support of the New DevWorkspace CR engine product architecture

An OpenShift CRD and Controller is handling workspace containers, rather than CodeReady Workspaces server. This transfer of responsibility enables a better orchestration. To manage the workspaces, OpenShift native tools and APIs are available, rather than a CodeReady Workspaces-server REST API using services of a custom CRD.

It enables:

  • A delegation to the OpenShift authentication using RBAC and persistence using ETCD key-value store.
  • Easy provisioning of CodeReady Workspaces workspaces using OpenShift APIs
  • More advanced workspace control, such as the configuration of a workspace based on users' geographic location or automatically disabling plug-ins deteriorating workspaces performances.

Additional resources

2.2. Improved start-up time using the Image Puller

The Image Puller can pre-download any CodeReady Workspaces image on all the nodes of an OpenShift cluster. The operator-metadata image doesn’t need pre-pulling and is not supported.

Additional resources

2.3. Tech-preview support of Devfile 2.0 specification

The Devfile allows for the definition of development environments in a repeatable and shareable manner. The specification continues to evolve as more tools, such as odo, adopt Devfiles and expand their usage. We are progressively introducing support in CodeReady Workspaces for the Devfile v2.x to allow for the following:

  • increased interoperability between tools
  • a simpler experience defining workspaces
  • new implementation possibilities with the DevWorkspace engine With Devfile v2.x, IDE plug-ins are no longer a core component and are instead included and managed by references to external files.
  • In CodeReady Workspaces 2.9, Che-Theia plug-ins can not be included in the devfile version 2.0-based workspace. This capability will be added in a subsequent release which includes support for the Devfile v2.1 specification.
  • Workspaces based on devfile version 1 remain fully supported.
  • The support for Devfile 2.0 is disabled by default. To enable this support, set spec.devWorkspace.enable: true in the CheCluster Custom Resource.

  • CodeReady Workspaces 2.9 requires new containers for enabling the devfile 2.0 support:

Additional resources

2.4. Upgrade VS Code YAML plug-in to 0.14.0

The VS Code YAML plug-in has been updated to version 0.14.0.

Additional resources

2.5. Deprecate the VS Code Asciidoctor plug-in

The VS Code Asciidoctor plug-in has been deprecated and will be removed in the future release.

Additional resources

2.6. Memory limits are handled at the plug-in and devfile levels

Memory limits are handled at the plug-in and devfile levels. The globalMemory limits have been removed from the meta.yaml files inside the devfile registry.

Additional resources

2.7. Add resources limits and requests to che-machine-exec and remote-runtime-injector plug-ins

The che-machine-exec and remote-runtime-injector plug-ins have defined resource limits.

Additional resources

2.8. Upgrade VS Code Language support for Camel K to 0.0.24

The VS Code Language support for Camel K has been updated to version 0.0.24.

Additional resources

2.9. Kubernetes Image Puller can pull images from a password protected registry

Users can pull images from private registries.

Additional resources

2.10. Multi-root mode by default

Some VS Code extensions must run in Multi-root mode. CodeReady Workspaces sets the Multi-root mode for all new workspaces.

To turn on the Multi-root mode in workspaces created in an earlier version, set the multiRoot parameter in the devfile: 

attributes:
  multiRoot: 'on'

Additional resources

2.11. CodeReady Workspaces is switching to the`per-user` namespace strategy

All namespace strategies except the per-user strategy are deprecated and will be unsupported with a future release.

This change:

  • Improves security.
  • Gives administrators better control over resources that are assigned to users by using namespace quotas.
  • Eliminates of the need to duplicate sensitive information using Kubernetes secrets, as with the per-workspace strategy.

Additional resources

2.12. Accessing GitLab private repositories from a factory URL

To access and authenticate a private GitLab repository using a factory URL pointer:

  1. Store a personal access token as a secret in the CodeReady Workspaces user namespace.
  2. Use a factory URL pointer to access and authenticate the private GitLab repository.

Additional resources

2.13. Support telemetry for Red Hat VS Code extensions in CodeReady Workspaces

CodeReady Workspaces optionally collects Red Hat telemetry data from extensions that support it.

Additional resources

2.14. Prompt users to provide an SSH key pair when using Git with SSH in a devfile

Upon starting a workspace whose devfile uses Git with SSH to clone a sample project, CodeReady Workspaces prompts you to provide an SSH key.

Additional resources

2.15. GitLab public repository support in a factory URL

CodeReady Workspaces supports workspace creation using a GitLab-based factory URL.

Additional resources

2.16. Support for Mermaid diagrams and flowcharts

The Bierner Markdown plug-in enables users to render Mermaid diagrams and flowchart graphs directly using Che-Theia Markdown preview.

Additional resources

2.17. The dashboard is running in a dedicated container

The dashboard is running in a dedicated container rather than in the CodeReady Workspaces server container.

Additional resources

2.18. The VS Code extensions update

  • cobol-language-support to v0.19.0
  • hlasm-language-support to v0.13.0
  • COBOL Control Flow to v0.4.0.

Additional resources