Releases: eclipse-che/che
Eclipse Che 7.48.0
Major Enhancements
Default Che URL prefix should be eclipse-che rather than che-eclipse-che
The default URL is now shorter and doesn't have the name che repeated twice in it. The URL prefix doesn't depend on the Kubernetes namespace where Che is deployed anymore but is always in the format eclipse-che.<cluster-domain>.
Always use OAuth flow to authenticate user against Git services (GitHub, Gitlab and Bitbucket) when a workspace starts
When starting a workspace for the first time users are prompted systematically to authenticate against the Git service provider if the OAuth flow has been enabled by the administrator. That allows to always inject personal tokens with git credentials in workspaces. That was done for private repositories only and it's now extended to any repository. The git services providers that are supported are GitHub SaaS, Gitlab on-prem and Bitbucket on-prem.
Include a link to go back to the dashboard in the workspace loading page
The workspaces loading page didn't had any link to get back to the dashboard. Now it's possible to click on a link on the top left of the page to get back to the dashboard and on a link that is shown when an error occurs.
Major Bug Fixes
No major bug fix in this release
VS Code extensions Updates
No VS Code extension update in this release
Eclipse Che 7.47.0
Major Enhancements
No major enhancement has been merged this month.
Major Bug Fixes
After login users get redirected to the dashboard although they used a link to start a workspace
With this fix users will be correctly redirected to the workspace after authentication.
VS Code extensions Updates
Update VS Code extension che4z-explorer-for-endevor to v1.1.0
Eclipse Che 7.46.0
Major Enhancements
Updating Che Dashboard and Che-Theia Node.js versions
Node.js 12 will go EOL on 2022-04-30, Che dashboard has been updated to Node.js v16 and Che Theia to v14 (for VS Code extensions compatibility).
Pair programming: enable usage of CodeTogether propsed API for better UX
This improve the UX of CodeTogether VS Code Extension in a Che workspace and for instance allows to share the terminal.
Add a resource monitoring extension for VS Code based Che workspaces
The resource monitoring extension tracks memory and cpu usage of the different components of a Che workspace. This is now a built-in extension of Che Code, the build of VS Code (Code OSS) for Che workspaces.
Major Bug Fixes
Start an ephemeral workspace fails
The fix allows to start workspaces in ephemeral mode, and therefore faster.
Chectl server:logs should get logs from all Che containers
With this fix Che command line tool chectl is downloading the logs of all the server components of Che, including the gateway.
VS Code extensions Updates
#1236 Update VS Code extension che4z-explorer-for-endevor to v1.0.1
Eclipse Che 7.45.0
Major Enhancements
Che administrators can specify a header message on User Dasboard visible to every user
It's now possible to customize Che User Dashboard, Che users landing page, to show a message that has been setup by the administrator. The message will be visible to every user that will have access to Che User Dashboard.
Major Bug Fixes
N/A
Plugins Updates
N/A
Eclipse Che 7.44.0
Major Enhancements
Che-Theia Plugins view support for DevWorkspace based workspaces
Che-Theia now supports plugins management from the built-in Plugin View for DevWorkspace based workspaces as well.
Support for devfile v2 parents
The Devfile v2 specification introduced the concept of parent that allow to reference an existing Devfile. Che now supports that with DevWorkspace based workspaces.
Major Bug Fixes
After upgrading to Che v7.42 it was not possible to start workspaces if the TLS ConfigMap size was bigger than 1KB
After upgrading to Che v7.42, workspaces startup failed if the TLS bundle ConfigMap size was > 1KB. To address that HTTP2 had to be disabled in the che-server to Kubernetes API.
Fix the restart of che-code based workspaces
Workspaces that use che-code as an editor failed to restart or start (if stopped). This has been fixed in this release.
Plugins Updates
Upgrade Language Support for Apache Camel by Red Hat VS Code extension to v0.1.5
Eclipse Che 7.43.0
Major Enhancements
Auto opening cloned project in JetBrains' related editors
Now, when using a Devfile to start a workspace using a JetBrains IDE, the projects from the Devfile are shown in the IDE after startup.
Connect automatically to an OpenShift cluster with the OpenShift Connector VS Code extension
Users token gets automatically injected in the workspace pods at startup and the OpenShift Connector VS Code extension leverages that now. This was already the case for Che server based workspaces and now DevWorkspace based workspaces support it too.
Changes to Che-Theia preferences are persisted in a ConfigMap
When Che-Theia user preferences (including plugins preferences) are changed, they are persisted in a Kubernetes ConfigMap. When a workspace is restarted or when a new workspace is created the existing user preferences will be loaded. There is still a bug that prevents color theme preferences to be persisted. This is something that was already working with Che server based workspaces.
On prem private Gitlab repositores support with OAuth2 flow (without Keycloak)
Che with the DevWorkspace engine now supports on premise private Gitlab repositories. On premise private Bitbucket and github.com private repositories were already supported. Bitbucket Cloud and gitlab.com are not supported yet.
Support for namespace-level configuration of pod tolerations and node selector
It is now possible to specify pod tolerations and node selector for workspaces of a Che instance setting a CustomCheProperty in CheCluster CR. It's not possible to specify that for just one workspace or for one user: it's a global config.
20+ seconds faster Che-Theia startup
The previous DevWorkspace based Che-Theia used to take more than 20 seconds to load due to some blocking built-in plugins startup. Now the built-in plugins are not blocking the main Theia process startup anymore.
Plugins updates
Eclipse Che 7.42.0
Major Enhancements
Switch to the DevWorkspace Operator as workspace engine
The stable channel of Che operator has the DevWorkspace enabled by default and use the operator "all-namespace" installation mode. The other channels are being deleted. After more than one year of work, and after introducing it as an experimental option in Che 7.28, we have switched to the new workspace engine. 🎉
Why are we doing this?
Scalability and HA
The new engine is a Kubernetes controller. As such it runs behind the kube-apiserver that is designed to scale horizontally. The data is persisted in a key value store designed to be highly available (etcd).
A universal API
Workspaces are Kubernetes object:
- Kubernetes clients such as kubectl or the OpenShift console can manage them
- They are secured via RBAC
- They can be validated and protected by admission webhooks
- The devfile specification is automatically generated from the API
A simpler design
The new workspace engine has a single responsibility that is to manage workspace resources. It's decoupled from the developers IDEs and from the server side components of Che. Communications between components happens asynchronously using ConfigMaps and Secrets rather than a REST API.
A refactoring opportunity
The new engine has been written from scratch and we took the opportunity to address legacy issues:
- Simpler configuration of the Che operator
- No hard dependency on Keycloak but any OIDC provider can be used for authentication
- Introduction of a single gateway to simplify the network model and the TLS certificates management.
What's changing?
For an admin
- Deploying Che is simpler because there are less configuration options. For instance the namespace strategy and the exposure strategy are set to "per-user" and "single-host" respectively as we have observed that that’s what users want anyway.
- Che can be linked to any OIDC provider to enable authentication. We are not tied up to Keycloak anymore and Dex is deployed by default on minikube.
- Deploying multiple instances of Che on the same cluster is not possible anymore. That will avoid problems due to conflicting versions of Che running on the same cluster.
For a user
- Workspaces use Devfile v2 that has some significant improvements compared to v1 as parents and events.
- Devfiles are IDE agnostic and don't include plugins definitions anymore. IDE specific configurations are managed in separate files as VS Code extensions.json.
- Some redundant getting started samples have been removed.
- Workspaces IDEs don’t run in an iframe anymore
Should I upgrade to v7.42 as soon as it is released or should I wait?
It's ok to deploy v7.42 in the case of a first installation of Che or for a non-production environment. You will benefit from the new features right away.
You should wait if instead you are an existing user and you don’t want to lose existing workspaces data. For existing users we recommend waiting for v7.44 of Eclipse Che, when we plan to release an automated workspace migration functionality.
More Links
Finally here are some links to learn more about the new feature:
- The endgame plan
- The initial architectural documentation
- Milestones that led to v7.42
- A couple of blog posts related to the new engine (more are coming in the next weeks):
- Devfile v2 website
- DevWorkspace Operator
- (7.)42 is the answer :-)
Kudos to the whole Che team that worked hard on this challenging pivot 💪
Dashboard should be be able to group samples in dedicated group
The samples in the user dashboard are labelled as community .For downstream version of Che samples are labelled
tech-preview.
Plugins updates
No update during this sprint
Eclipse Che 7.41.0
Major Enhancements
Introduce a new operator-based Helm chart and publish it on ArtifactHub. Remove chectl helm installer.
The old Helm chart has been replaced with a new one that reuse Che Kubernetes operator to deploy Che. The new Chart has been published on ArtifactHub. We have removed the helm chart installer in chectl: to install the new Chart users are required to use helm command line tool
Fix Docker Desktop deployment
Docker Desktop deployment of Eclipse Che was not working due to some outdated templates to install the nginx routing controller. The templates have been updated to the latest version.
Java language support was slow due to low CPU limit
During startup and at runtime the Java language server was throttled because it required more CPU than the limit set by the container runtime. The CPU limit was increased from 500MB to 800MB.
Upgrade logback to v1.2.9
Related to https://jira.qos.ch/browse/LOGBACK-1591 and https://cve.report/CVE-2021-42550
Plugins updates
Eclipse Che 7.40.0
Major Enhancements
Improved Operator memory consumption
Fixed an operator issue that forced to augment the memory requirement based on the number of the namespaces on the cluster
Set resources requests and limits for workspace initialization containers
Plugin artifact broker and remote runtime injector are containers created during workspace initialization. Those containers failed to run in clusters where CPU and memory request had to be specified for every container. Che sever has been updated to specifies CPU and memory request and limits for every container it starts. Values are configurable.
Support customizing the PVC size for the internal PostgreSQL instance
CheCluster CR now has a database.pvcClaimSize field where administrators can specify a custom value for the database persistent volume. This is important because some public cloud providers' cloud disk does not support 1Gi, the minimum storage size is 10Gi.
Introduce a NodeJS library to convert devfiles from v1 to v2 and viceversa
We introduced a new Devfile conversion library https://www.npmjs.com/package/@eclipse-che/devfile-converter. Che Dashboard uses it. It can be included in any nodeJS project that requires it.
Plugins updates
Eclipse Che 7.39.0
Major Enhancements
Support v2 devfiles with che-server by converting them into corresponding v1 devfiles (backported to 7.38.x)
Che now supports creating workspaces from a Devfile that uses v2 of the spec even if the workspace engine is the che-server (the default). Previously that was possible only if Che was configured with the DevWorkspace operator as workspace engine.
Added a link to the OpenShift console from Che dashboard
The new link in the About section of the User Dashboard helps developers access the OpenShift Console from Che
Plugins updates
N/A