Chapter 2. New features and enhancements

Communications with external services are encrypted with TLS and require the certificates to be signed by trusted Certificate Authorities (CA). Therefore, all untrusted CA chains used by external services should be imported to Dev Spaces.

Starting from this release, labeled ConfigMaps from the installation namespace are used as sources for TLS certificates. The ConfigMaps can have an arbitrary amount of keys with an arbitrary amount of certificates each. The operator merges all ConfigMaps into a single one titled ca-certs-merged, and mounts it as a volume in the operands and Cloud Development Environment (CDE) pods.

By default, the operator mounts the ca-certs-merged ConfigMap in a user’s CDE at two locations: /public-certs and /etc/pki/ca-trust/extracted/pem. The /etc/pki/ca-trust/extracted/pem directory is where the system stores extracted CA certificates for trusted certificate authorities on Red Hat (e.g. CentOS, Fedora). CLI tools automatically use certificates from the system-trusted locations when the user’s CDE is up and running.

Learn more about the procedure in the official documentation.

Starting from this release, you can configure two Gitlab OAuth providers on a single Dev Spaces instance. This can be particularly useful when developers are working with codebases hosted on both GitLab SaaS and on-premises.

Learn more about the procedure in the official documentation.

With this release, you can create or import the .gitconfig file from the User Dashboard regardless of the authentication method setup on the cluster.

Before this release, it was not possible to create or import the .gitconfig file if you were logged in via LDAP or local authentication. Instead, you had to manually create a dedicated config map for the .gitconfig file in their namespace.

This official documentation defines minimal permissions for installing Dev Spaces on an OpenShift cluster using CLI or web console UI starting from this release.

When setting the discoverable: true attribute on a devfile container component endpoint, a dedicated service will be created and used for the endpoint. For all other endpoints that do not set the discoverable: true attribute, the common workspace service will be used.

The dedicated service created for the endpoint will have a static name, corresponding to the endpoint’s name. For example, a service named http-python will be generated in the example endpoint defined below:

# Example endpoint with discoverable attribute
- exposure: public
  targetPort: 8080
  name: http-python
  protocol: http
  secure: true
  attributes:
    discoverable: true

With this release, you can leverage the OpenShift Template object and replicate the resources defined in it across the namespaces of all users, such as:

*LimitRange *ResourceQuota *NetworkPolicy *Role *RoleBinding

Learn more about the procedure in the official documentation.

Starting from this release, if cluster autoscaler is provisioning a new worker node during Cloud Developer Environment (CDE) startup, you will be notified with a dedicated warning message.

With this release, you can install default Visual Studio Code - Open Source ("Code - OSS") extensions using the combinations of the devfile postStart event together with automount ConfigMap:

  - id: add-default-extensions
    exec:
      # put your tooling container name here
      component: runtime
      commandLine: |
        # download regular binary
        curl open-vsx.org/api/atlassian/atlascode/3.0.10/file/atlassian.atlascode-3.0.10.vsix --location -o /tmp/atlassian.atlascode-3.0.10.vsix
        curl open-vsx.org/api/snowflake/snowflake-vsc/1.9.1/file/snowflake.snowflake-vsc-1.9.1.vsix --location -o /tmp/snowflake.snowflake-vsc-1.9.1.vsix

events:
  postStart:
    - add-default-extensions

With this release, the security best practices for Dev Spaces are available in the official documentation.

When the activity tracker extension could not ping the idler service, there was no user-facing error message displayed. This could cause a situation where your Cloud Development Environment (CDE) is terminated due to the idler, even when you are actively using your CDE. With this release, an error notification warns you when the idler service cannot be reached.

With this release, the Enabling fuse-overlayfs for all workspaces document is updated to include support for Podman 5.x.

With this release, registry.redhat.io/devspaces/udi-rhel9 is used as the default development image. To override it, use the spec.devEnvironments.defaultComponents Custom Resource property:

spec:
  devEnvironments:
    defaultComponents:
       - name: universal-developer-image
         container:
           image: <>