Chapter 2. New features and enhancements

Previously, the che-code editor failed to start on workspaces that used a Red Hat Universal Base Image (UBI) 10. This issue is now resolved.

You can now use UBI 10-based images in the components section of a devfile. For example:

schemaVersion: 2.3.0
metadata:
  name: ubi10-minimal-demo
components:
  - name: tools
    container:
      image:  registry.access.redhat.com/ubi10-minimal@sha256:53de6ac7c3e830b0ddfc9867ff6a8092785bcf156ab4e63dfa9af83c880fd988
      args: ['tail', '-f', '/dev/null']
      endpoints:
        - exposure: public
          name: nodejs
          protocol: http
          targetPort: 3000
      memoryLimit: 2Gi
      memoryRequest: 256Mi
      mountSources: true
    attributes:
      controller.devfile.io/merge-contribution: true

You can find available UBI 10 images in the Red Hat Ecosystem Catalog.

There is a new udi-base base image based on Red Hat Universal Base Image (UBI) 10, providing a more recent operating system and access to updated packages for all workspaces.

Starting from this release, Dev Spaces pre-creates two ClusterRoles during installation to simplify administration and GitOps integration. You can reference these roles directly in ClusterRoleBindings without needing to define them manually.

The new roles are:

For more information, see the documentation about Managing identities and authorizations.

You can now set CPU and memory limits by using new input fields in the Advanced Options menu on the Dashboard.

When the spec.devEnvironments.persistUserHome feature is enabled, you can specify files to be copied from /home/tooling/ to /home/user/ instead of being symbolically linked. This is useful for configuration files that you want to edit and have the changes persist.

To specify which files to copy, create a .copy-files file in the /home/tooling/ directory of your Universal Developer Image (UDI). In your Dockerfile, add the names of the files to this list.

For example, to copy the .my-config file:

FROM quay.io/devfile/base-developer-image:ubi9-latest
...
RUN echo ".my-config" >> /home/tooling/.copy-files
...

You can now use external tools, such as cert-manager, to manage the TLS configuration for workspace routes. When this feature is enabled, the Dev Spaces operator does not revert any custom TLS settings that are applied to these resources.

To enable this feature, configure the externalTLSConfig field in the CheCluster custom resource:

spec:
  devEnvironments:
    networking:
      externalTLSConfig:
        // Enabled determines whether external TLS configuration is used.
        // If set to true, the operator will not set TLS config for route objects.
        // Instead, it ensures that any custom TLS configuration will not be reverted on synchronization.
        enabled: <bool>
        // Labels to be applied to route objects when external TLS is enabled.
        labels: <map[string]string>
        // Annotations to be applied to route objects when external TLS is enabled.
        annotations: <map[string]string>

To reduce the number of resources created in each user namespace, the following ConfigMaps are now consolidated into a single ConfigMap named che-user-settings:

You can now configure default resource requests and limits for all workspace containers by using the new spec.devEnvironments.defaultContainerResources field in the CheCluster custom resource.

To configure the default resources, add the defaultContainerResources field:

spec:
  devEnrinoments:
    defaultContainerResources:
      limits:
        cpu: 200m
        memory: 200Mi
      requests:
        cpu: 100m
        memory: 100Mi

When you create a workspace from a Git repository, you can now specify a branch for repositories that use an SSH URL. On the Import from Git page, use the new Git Branch field under Git Repo Options to enter the name of the branch.

This release introduces smarter handling of factory URLs to prevent the accidental creation of duplicate workspaces.

When you create a workspace by using a factory URL from a Git repository:

You can also use URL parameters for more direct control:

Additionally, for sample projects on the Create Workspace page, you can now use the Create New switch to control this behavior. When the switch is enabled, a new workspace is always created. When disabled, an existing workspace from that sample is reused if it exists.

For more information about using these parameters, see the documentation about Starting a workspace from a Git repository URL.

This release includes the following key updates.

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
  name: devworkspace-operator-config
  namespace: openshift-operators
config:
  workspace:
    hostUsers: false

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
  name: devworkspace-operator-config
  namespace: openshift-operators
config:
  workspace:
    postStartTimeout: 30s