Burn Eclipse Che to the ground

Eclipse Che is the worst piece of software I have ever seen, likely the worst that exists. It's worse than Windows, worse than PHP, worse than systemd, worse than twitter.com, worse than anything made by Intuit.

Intuit has shitty software engineering

Premise

The sheer horror of this software starts with its very premise. What is Eclipse Che? It is a way to run a web-based IDE on a Kubernetes cluster.

What???

If that sentence doesn't make you say "what the fuck", please stop programming.

My background with Che comes from using it as a contractor at a startup trying to make a web service that uses a Kubernetes cluster. The web service's point is basically to give out exercises to job candidates that are more realistic than the industry status quo; the web service sets up a container on the Kubernetes cluster and asks the candidate to SSH into it and complete a challenge. This worked, it was great, however boss decided that replacing the SSH login with an in-browser IDE would have more "wow factor", and Che was chosen for this.

One disclaimer before I get into the specific problems: since this software changes so fast, there's a good chance a lot of this will be outdated by the time you read it and replaced with new problems. I'm not going to put in the effort to keep this article up to date.

Kubernetes disaster

Incase you thought I meant that Che just runs in *a* pod on a Kubernetes cluster: no. It spans an entire federation of pods: a server pod, a gateway pod, an operator pod, a Postgres pod, a pod for the plugin registry, a pod for the devfile registry, a pod for the web interface.

It even relies on stuff outside of the eclipse-che namespace in your cluster. Our kubernetes distribution, k3d, sets up an ingress (network entrypoint) called traefik by default, but that didn't work because Che was set to expect something called ingress-nginx to be installed on the cluster. And there is no documentation about that expectation. It just requires that and you have to figure out that you're supposed to install the ingress-nginx plugin.

We tried configuring it to use the traefik ingress. However that led to Che using a directly self-signed cert instead of a cert signed by a generated certificate authority, which meant the instructions given by chectl output for importing its certificate authority into a browser didn't work; we had to whitelist each of the many domains it uses manually. It also led to some errors creating workspaces that I don't remember. Basically it doesn't work with the default traefik ingress and we had to use ingress-nginx. (Why that has *any* effect on the cert it uses, I don't fucking know.)

The delete command also doesn't remove the user namespace (eg. username-che), which is separate from the eclipse-che namespace (I wonder what happens if you have a user named eclipse?), and I've seen this cause problems before where the cluster is in some invalid state and the delete command doesn't fix it, I have to also delete the namespaces.

OIDC debacle

Che is designed to force the use of an *external identity provider* using a protocol called OpenID Connect. In theory you could configure it so you log in to Che with Google, I guess, if you wanted to bootlick oligopolies and give them even more power. I say "in theory" because in practice nobody could figure out how to make this software actually work.

What if you just want a simple setup where you manage the accounts yourself? Absolutely not, not supported. You *must* use an OIDC provider. Older versions of Che came with a builtin instance of Keycloak, a self-hostable OIDC provider. However newer versions don't have it and you would have to set up Keycloak yourself to use them - and Keycloak is itself a behemoth of complexity and poor documentation that you'll spend a week trying to set up, believe me I tried.

Thus, we had to roll back to an older version - v7.41.2 - for our use case, which has the builtin Keycloak.

Oh, and the latest version when we started was v7.46.0. Notice what that means? They're using semver wrong! They made a huge breaking change without incrementing the major version! This is made even worse by... something I'll get to.

Documentation

The whole thing is barely documented. Their web documentation leaves a lot to be answered, and there are pages in the old version of it that have no equivalent in the new version and so redirect to something irrelevant when you click the "stable" link.

A deployed Che instance has a page you can visit with Swagger docs on the API for controlling workspaces. However, *in v7.41.2*, it only documents the new *devworkspace* API that isn't even enabled by default in v7.41.2, and not the older *workspace* API that this version actually uses. So that was useless to me. I couldn't find any documentation on the old API anywhere; apparently they deleted all trace of it from the web even though this version is *only 3 months old*. I had to reverse engineer the API.

As for enabling devworkspaces so we could use the documented API? I couldn't. Apparently that requires a bunch of special extra configuration that isn't documented anywhere.

Bugs

I also saw plenty of banal bugs. For example, when I create a workspace from its dashboard, it immediately says "Error: workspace failed to start" as it starts the creation process. And there's a place you can see logs from the creation process, but after my first few days with this software it mysteriously stopped working - the logs were just always empty. After another few days it started working again, then stopped working.

The "New File" button in the IDE just does nothing for me.

When signing in through the included Keylcoak instance, the forgot password page includes the text `<br/>`.

Evil self-update

This one is so horrifying I felt like I'd have trouble even getting my boss to believe me when I started seeing the symptoms. In fact, let me tell you the symptoms first:

I was trying to do some stuff in an Ubuntu VM to see if any of the problems I was having were because Artix isn't a sufficiently mainstream distribution for Che to work properly on it. I had downloaded chectl v7.41.2 in Ubuntu, it was behaving just like it was on the Artix host, then one day when trying to recreate the cluster in the VM I got an error suggesting I was running v7.46.0. I ran `chectl version`. Somehow, the binary I had downloaded was v7.46.0.

I tried redownloading the v7.41.2 release from Github. It was, right out of the box, v7.46.0.

And yet the size of the download was different from the size of the v7.46.0 download, so I must've been getting the right download!

Bizarre, right? Feels like being gaslit. Let me link the issues I made about this:

https://github.com/che-incubator/chectl/issues/2027

https://github.com/eclipse/che/issues/21366

That's fucking right: **Eclipse Che secretly self-updates to incompatible versions while running.**

And let me add that whenever you run a chectl command with an older version it warns you and asks you if you want to update - but I never said yes to that question!

chectl's terminal handling

chectl reads your terminal width and does some dastardly homecooked stuff with it. When showing the message `Documentation how to add a CA certificate into a browser: https://www.eclipse.org/che/docs/che-7/end-user-guide/importing-certificates-to-browsers/`, it inserts its own line-breaks, which has two consequences:

If you expand your terminal window to see it all on one line, it stays broken.
If your terminal lets you click on URLs and you try to click on this, it'll get only the first line of the link, and you'll get a 404 and be confused.

An even worse thing it does with some other output (no, it doesn't even treat all output the same way), such as messages explaining why your Che configuration is invalid, is *actually truncate the message at one line* so you literally can't see why your configuration is invalid. And the message I saw this with was too long to fit even in a full-screen terminal with a small font size.

Jesus guys, terminals handle line breaks so you don't need to do any of that shit! You literally don't have to do anything to get this to behave right, just *don't go out of your way to break your software!*

Branding

There are also some appalling issues with their support for custom branding. While it's completely unfair to ask for free software to add support for corporate users to deny them a mere attribution, they did decide to add such features, so I think issues with those features are a fair example just of how bad their software engineering is.

(Link to their documentation rotted of course)

They don't really explain why it's necessary to build their plugin registry repository; the answer is just to get the YAML file that describes the spec for the IDE container. And there's issues with the procedure for building the plugin registry repository itself - they really only considered the most mainstream use case. For example, I was trying to build it with a docker registry that is only served over HTTP, so I put in my registry address as they show, and got confusing error messages because apparently only HTTPS registries are supported and they just assume you know that. Eventually what I had to do was build it with *their* registry, then manually edit the YAML file.

And if your product.json has certain fields empty, such as the icon or logo images, it just silently ignores the whole file and reverts to the default branding. There is no documentation about that.

See that comment on the links field in the product.json, that says "Use tags to group links to make them easier to find."? It doesn't say what that means, what are "tags" and how can you use them. There are no other occurrences of that word in the document.