che Documentation

Kubernetes based Cloud Development Environments for Enterprise Teams

7,170 stars TypeScript TypeScript 5 files · ~4,588 tokens #cloud#cloud-ide#containers#devtools#eclipse#ide#kubernetes
RAW Doc

Docker & Self-Hosted Deployment Verified OCI

Deploy che on any server, homelab, or cloud container platform.

1-Click Terminal Command
bash (docker run) 
docker run -d --name che --restart always eclipse-che/che:latest

Technical Documentation: eclipse-che/che

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`)

Visit website at: https://eclipse.dev/che/ and documentation at: https://eclipse.dev/che/docs

Getting Started

Here you can find links on how to get started with Eclipse Che:

Using Eclipse Che

Start a workspace from a Git repository

Open any Git repository as a Cloud Development Environment by navigating to your Che instance with a factory URL:

text
https://<your-che-host>/#https://github.com/<owner>/<repo>

For example, to open this repository:

text
https://<your-che-host>/#https://github.com/eclipse-che/che

Start a workspace using chectl

Use the chectl CLI to create and manage workspaces:

bash
# Start a workspace from a devfile
chectl workspace:start -f devfile.yaml

# Start a workspace from a remote devfile
chectl workspace:start -f https://raw.githubusercontent.com/eclipse/che/main/.devfile.yaml

# List running workspaces
chectl workspace:list

# Stop a running workspace
chectl workspace:stop <workspace-id>

Define a workspace with a devfile

Add a devfile.yaml to your repository root to define your development environment:

yaml
schemaVersion: 2.3.0
metadata:
  name: my-project
components:
  - name: devtools
    container:
      image: quay.io/devfile/universal-developer-image:ubi9-latest
      memoryLimit: 4G
      mountSources: true
commands:
  - id: build
    exec:
      commandLine: 'mvn clean install'
      component: devtools

When a devfile.yaml is present, Che automatically configures the workspace with the specified tools, runtimes, and commands.

Learn more

Feedback and Community

We love to hear from users and developers. Here are the various ways to get in touch with us:

Contributing

If you are interested in fixing issues and contributing directly to the code base:

Extending Eclipse Che

Roadmap

We maintain the Che roadmap in the open way. We welcome anyone to ask question and contribute to the roadmap by joining our community meetings.

License

Eclipse Public License 2.0.

Overview (`tests/devworkspace-happy-path/README.md`)

Che DevWorkspace Happy Path

This folder holds the scripts and resources which allows you to run Che DevWorkspace Happy path with help of Pod on the cluster against already deployed Che (with DevWorkspace engine) on the same cluster.

Running locally

If you have Che with DevWorkspace enabled on the current cluster, you can just run

bash
./launch.sh

Running remotely

If you need to run this as PR check, you need to predeploy Che with DevWorkspaces enabled
and then invoke remote-launch, possibly via curl:

bash
curl -s https://raw.githubusercontent.com/eclipse/che/main/tests/devworkspace-happy-path/remote-launch.sh | bash -s

Overview (`tests/e2e/README.md`)

Requirements

  • node 16.x
  • "Chrome" browser 114.x or later
  • deployed Che 7 with accessible URL

Before launch

Perform commands:

  • export TS_SELENIUM_BASE_URL=<Che7 URL>
  • npm ci

Note: If there is any modifications in package.json, manually execute the npm install to update the package-lock.json. So that errors can be avoided while executing npm ci

Default launch

  • Provide connection credentials:
    • export TS_SELENIUM_OCP_USERNAME=
    • export TS_SELENIUM_OCP_PASSWORD=
    • npm run test

Custom launch

  • Use environment variables which described in the "constants" folder
  • Use environment variables for setting timeouts if needed. You can see the list in 'TimeoutConstants.ts'. You can see the list of those variables and their value if you set the 'TS_SELENIUM_PRINT_TIMEOUT_VARIABLES = true'
  • To test one specification export file name as export USERSTORY=<spec-file-name-without-extension> && npm run test (example: -e USERSTORY=Quarkus)
  • To run test without Selenium WebDriver (API tests etc.) use export USERSTORY=<spec-file-name-without-extension> && npm run driver-less-test (example: -e USERSTORY=CloneGitRepoAPI)
  • This project support application testing deployed on Kubernetes or Openshift platform. Openshift is default value. To switch into Kubernetes, please, use TS_PLATFORM=kubernetes environmental variable and TS_SELENIUM_K8S_PASSWORD, TS_SELENIUM_K8S_USERNAME to provide credentials. The sample of test command in this case:
    text
    export TS_PLATFORM=kubernetes && \
export TS_SELENIUM_K8S_USERNAME=<username> && \
export TS_SELENIUM_K8S_PASSWORD=<password> && \
export TS_SELENIUM_BASE_URL=<ingress-url> && \
npm run test
    Also, environmental variables can be set in files in "constants" folder.
  • Local test results can be represented with Allure reporter npm run open-allure-dasboard

Docker launch

  • open terminal and go to the "e2e" directory
  • export the "TS_SELENIUM_BASE_URL" variable with "Che" url
  • run command "npm run test-docker"

Docker launch with changed tests

For launching tests with local changes perform next steps:

  • open terminal and go to the "e2e" directory
  • export the "TS_SELENIUM_BASE_URL" variable with "Che" url
  • run command "npm run test-docker-mount-e2e"

Debug docker launch

The 'quay.io/eclipse/che-e2e' docker image has VNC server installed inside. For connecting use '0.0.0.0:5920' address.

The "Happy Path" scenario launching

The easiest way to do that is to perform steps which are described in the "Docker launch" paragraph. For running tests without docker, please perform next steps:

Launching the DevWorkspaceHappyPath spec file using Che with oauth authentication

Setup next environment variables:

  • export TS_SELENIUM_BASE_URL=<Che-URL>
  • export TS_SELENIUM_OCP_USERNAME=<cluster-username>
  • export TS_SELENIUM_OCP_PASSWORD=<cluster-password>
  • export TS_SELENIUM_VALUE_OPENSHIFT_OAUTH="true"
  • export TS_OCP_LOGIN_PAGE_PROVIDER_TITLE=<login-provide-title>
  • export TS_SELENIUM_DEVWORKSPACE_URL=<devworkspace-url>
  • export TS_SELENIUM_HAPPY_PATH_WORKSPACE_NAME=EmptyWorkspace (default value, see BASE_TEST_CONSTANTS.ts)

Execute the npm command:

  • perform command export USERSTORY=$TS_SELENIUM_HAPPY_PATH_WORKSPACE_NAME && npm run test-all-devfiles

Overview (`tests/performance/README.md`)

Load tests

Load tests should test the behaviour of server when users will start workspace at once.

Prerequisites

Test itself is just creating a load so there are some steps that need to be done before running load tests.
What do you need to run those tests

  • oc client, jq and tar installed
  • cluster with running Che/CRW
  • cluster where load tests pods will be executed (can be the same cluster where Che/CRW is deployed)
  • users created on a Che/CRW (see 'How to create users' below)

How to create users

Users can be created manually, but there is a script create_users.sh to create users automatically.

Creating users via script

Log in via oc to the server and namespace, where the Che/CRW is running.
Type create_users.s -h to see how to run the script. The script will generate users based on base part of username and will add an increment to that.

text
-n    base part of username (e.g. 'user')
-p    common password
-s    starting index of a users (generated name will look like e.g. 'user1')
-c    number of users that should be created
-e    tested environment - can be Che or CRW

Examples:
The Che is running without any users created yet. 5 users can be created here by this command:

text
./create_users.sh -n user -p pass123 -c 5 -e Che -s 1

There are 5 users created user1, user2, user3, user4, user5. All users have common password pass123.
Now 5 users exist and can be used for load tests. Let's add another 10!

text
./create_users.sh -n user -p pass123 -c 10 -e Che -s 6

New users user6, user7, ..., user25 are created.

Running load tests

The command ./load-tests.sh -h can be executed to give a help with setting up all required parameters.

Setting up users

There are two ways how to tell the load tests which users to use. Users can be written in .csv file in format user,password. Use -c <my_file_with_credentials>.csv to use all users in your file.
The second way is usable when username are composed in format ``. To use that approach set those parameters:

text
-u    base username
-p    common password
-n    number of users

Please note that currently it is not possible to start from another index then 1.

Example:
Let's consider Che with 15 users created in format user1, user2, etc. and with password pass123. Then the setting of those values would be: -u user -p pass123 -n 15.

Additional parameters
There is non mandatory parameter that can be used:
-t defines how many workspaces will user create in a row. Default value is one. That basically means that whole test flow will be run again - so only one workspace will run at one time.

Other parameters

-i sets the image that include test. This image is used as a base image for a pods where test runs.
-r Che/CRW url where user can log in.
-f full path to folder where logs and reports should be saved

Results and logs

Once tests are done, logs and reports are copied from the pods to the local folder specified by -f flag. The structure looks like this:

Each time the test is run, new folder with timestamp as its name is created. All files are saved in this folder.

User folder

Each user has own folder with logs which is named in a way -<timestamp>. The timestamp is a time when this particular user test was started. If tests succeed, there are console-log.txt and load-test-folder in user folder. In load-test-folder there is just one file load-test-results.txt with test names and time taken by those tests.
If tests fail, there is also another folder called report. There are screenshots and logs from the failed test so it should be easier to understand what happened.

Pod conole log files

For each running pod there are logs gathered in a file pod-<number_of_pod>-console-logs.txt. Please note that if you set -t larger then 1, this pod console log contains logs only from the last run.

API performance tests

API performance tests use test scripts from crw-jenkins(https://gitlab.cee.redhat.com/codeready-workspaces/crw-jenkins/-/tree/master/vars) repo.

Running API load tests

To start API tests use ./api-load-tests.sh script with next parameters:

  • -n - number of users
  • -c - number of workspaces per user
  • -o - OCP URL
  • -b - Che URL
  • -u - username
  • -p - password
  • -s - test suite to run

Example:
This script will run API test for 10 users with 10 workspaces and cpp test suite:
./api-load-tests.sh -u user -p password -b https://devspaces.apps.ocp410.com -o https://api.ocp410.com:6443 -n 10 -c 10 -s cpp .

Dockerfile

Dockerfile is used to build image with all required dependencies to run API tests. It is used in api-pod.yaml script. It based on openshift/origin-cli:latest image and adds jq and yq packages.

Overview (`tests/performance/load-tests/README.md`)

Overview

This script tests the performance of an OpenShift environment by running multiple workspaces simultaneously. It evaluates the system under test by checking the average results across all pods and identifying any failures that occur during the testing process.

Prerequisites

To run these tests, you will need:

  • The kubectl client installed
  • An OpenShift cluster with running OpenShift DevSpaces
  • A test user logged into the DevSpaces Dashboard (this ensures that user namespaces are created)

Running load tests

Follow these steps to run the load tests:

  1. Log in to the OpenShift cluster with OpenShift DevSpaces or Eclipse Che deployed from the terminal.
  2. Start the load-test.sh script from test/e2e/performance/load-tests. Set the number of workspaces to start using the -c parameter (e.g., ./load-test.sh -c 5). Set the timeout for waiting for workspaces to start using the -t parameter in seconds (e.g., ./load-test.sh -t 240).
  3. This script uses the local example.yaml file to start the workspaces.
  4. Alternatively, you can provide a link to the test devworkspace YAML file using the -l argument (e.g., ./load-test.sh -l https://raw.githubusercontent.com/eclipse/che/main/tests/performance/load-tests/samples/simple-with-editor-pvc.yaml).
  5. If you want to start workspaces in separate namespaces (one workspace per namespace), use the -s as flag option (e.g., ./load-test.sh -s ).
  6. The script will provide the average time for workspace starting and the number of failed workspaces.

Results and logs

If a workspace fails to start, the logs will be saved in the logs directory.

--- METRICS ---

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

#cloud Browse cloud catalog → #cloud-ide Browse cloud-ide catalog → #containers Browse containers catalog → #devtools Browse devtools catalog → #eclipse Browse eclipse catalog → #ide Browse ide catalog → ⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →