Major Enhancements
Warning users that creating a CDE from an unknown source could be dangerous
With this release, when you start a CDE from a URL, you are asked if you trust the authors of the repository since creating a workspace from unknown or untrusted sources could be dangerous.
Advanced configuration options for the 'Import from Git' flow
Starting from this release, it is possible to configure the container image, temporary storage, memory and CPU limits when starting a CDE using the "Import from Git" flow:
Move stow / kubedoc and other internal features to the Universal Base Image
Kubedock, podman, fuse-overlayfs, buildah, and skopeo have been moved from the universal developer image to the universal base image. This makes the universal base image a minimal image containing prerequisites for Kubedock and container image building within Eclipse Che CDEs.
Add pod placement capabilities for devworkspace-webhook-server and make it more robust
With this release, the devworkspace-webhook-server deployment configuration options are available in the global DevWorkspaceOperatorConfig (DWOC) including: replicas, pod tolerations and nodeSelector.
These configuration options exist in the global DWOC's config.webhook field:
apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
namespace: $OPERATOR_INSTALL_NAMESPACE
config:
routing:
clusterHostSuffix: 192.168.49.2.nip.io
defaultRoutingClass: basic
webhook:
nodeSelector: <string, string>
tolerations: <[]tolerations>
replicas: <int32> Note: In order for the devworkspace-webhook-server configuration options to take effect:
- You must place them in the global DWOC, which has the name
devworkspace-operator-configand exists in the namespace where the DevWorkspaceOperator is installed. If it does not already exist on the cluster, you must create it. - You must terminate the devworkspace-controller-manager pod and restart it so that the devworkspace-webhook-server deployment can be adjusted accordingly.
Additionally, the default replica count for the devworkspace-webhook-server deployment has been increased to 2 to increase availability.
Add DisableInitContainer field in the Custom Resource
The DisableInitContainer field has been added to the CheCluster CR. This field sets the config.workspaces.persistUserHome.disableInitContainer field in the operator-owned DWOC. This field whether the init container that initializes the persistent home directory should be disabled.
When the /home/user directory is persisted, the init container is used to initialize the directory before the workspace starts. If set to true, the init container will not be created, delegating the home persistence setup to the CDE's first container component's entrypoint. This field is not used if the devEnvironments.persistUserHome.enabled field is set to false.
The init container is enabled by default.
Deprecation and archivation of the 'che-devfile-registry' repository
The devfile registry hosted at registry.devfile.io is used by default for the Getting Started samples starting from the Eclipse Che 7.82.0. In this release, the Eclipse Che-specific che-devfile-registry repository has been archived and officially deprecated. For configuring the custom Getting-Started samples, the admin should leverage the dedicated k8s ConfigMap.
Find more details in the official documentation.
Bug Fixes
Inconsistency in the behaviour of the $PATH environment variable within Devfile
Previously, when commands were executed using the command definition in the devfile, they had a different $PATH compared to commands launched in containers defined within the components section. The defect has been fixed in this release.
User-provided environment variables can't reference $PROJECT_ROOT or $PROJECT_SOURCE
Previously, users were not able to reference the $PROJECT_ROOT or $PROJECT_SOURCE environment variables in their devfile environment variables. This issue has now been fixed in this release.
Workspace status flickering during startup
Previously, during a workspace startup, the status could have been unexpectedly changed to 'Stopped' even though the workspace started successfully. The defect has been fixed in this release, and the status changes are ignored during workspace startup.
Starting a new workspace with a clone of the specified branch doesn't work correctly if the repo doesn't have devfile.yaml
Previously, starting a new workspace with a clone of a specified branch didn't work correctly if the repository didn't have devfile.yaml. Instead, the default branch was always cloned after the CDE startup. The defect has been fixed in this release.
Branch detection for Azure does not work on the User Dashboard
Before this release, branch detection for Azure repositories was not working on the User Dashboard. The defect has been fixed in this release:
AzureDevops Git repos with white spaces in the URL
Previously, creating a CDE based on an AzureDevops Git repository which contained a blank space or special character in the URL resulted in the following Error: Unsupported factory location: "<Azure DevOps Repo Link>". The defect has been fixed in this release.
Failed to create the workspace by factory from Github Enterprise server public repo if PAT or OAuth not configured
Before this release, creating a workspace from GitHub Enterprise public repositories that have no personal access token (PAT) or OAuth configured resulted in the following error: "Failed to create the workspace. Cannot build factory with any of the provided parameters. Please check parameters correctness, and resend query." The defect has been fixed in this release.
Workspace start page goes to cyclic reload if refresh token mode is applied
Previously, using the experimental CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN feature could result in the cyclic reload sequence during CDE startup. The defect has been fixed in this release.
Learn more about the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN feature in the official documentation.
Invalidate previous tokens if refresh token mode is enabled
Previously, using the experimental CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN feature a new token was generated on each workspace start / restart, but the previous tokens were not removed. The defect has been fixed in this release.
Learn more about the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN feature in the official documentation.