# Technical Documentation: eclipse-che/che

> ℹ️ **Provenance:** Multi-Tier Ingestion · [CodeWiki Reference](https://codewiki.google/github.com/eclipse-che/che)

### Overview (`README.md`)

<div id="header" align="center">

[](https://workspaces.openshift.com#https://github.com/eclipse-che/che)
[&logo=eclipseche&color=FDB940&labelColor=525C86)](https://che-dogfooding.apps.che-dev.x6e0.p1.openshiftapps.com/#https://github.com/eclipse-che/che)

[](https://eclipse.dev/che/)

**Platform for providing Kubernetes-based Cloud Development Environments for Enterprise Teams**

[](https://github.com/codenvy/che/blob/master/LICENSE)
<a href="https://sonarcloud.io/dashboard?id=org.eclipse.che%3Ache-parent%3Amaster">
<img src="https://sonarcloud.io/images/project_badges/sonarcloud-black.svg" width="94" height="20" href="" />
</a>

*Che is Kubernetes-native and places everything the developer needs into containers in Kube pods including dependencies, embedded containerized runtimes, a web IDE, and project code. This makes workspaces distributed, collaborative, and portable to run anywhere Kubernetes runs ... [Read More](https://eclipse.dev/che/features/)*

</div>



---

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

- [**Getting Started**](#getting-started)
- [**Using Eclipse Che**](#using-eclipse-che)
- [**Feedback and Community**](#feedback-and-community)
- [**Contributing**](#contributing)
- [**Roadmap**](#roadmap)
- [**License**](#license)

---

### Getting Started
Here you can find links on how to get started with Eclipse Che:
- [Use Eclipse Che online](https://eclipse.dev/che/getting-started/cloud/)
- [Run Eclipse Che on your own Kubernetes cluster](https://eclipse.dev/che/docs/stable/administration-guide/preparing-the-installation/)


### 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:

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

For example, to open this repository:
```
https://<your-che-host>/#https://github.com/eclipse-che/che
```

#### Start a workspace using chectl

Use the [chectl](https://github.com/che-incubator/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

- [Customize Che workspaces for your projects](https://eclipse.dev/che/docs/stable/end-user-guide/customizing-workspace-components/)
- [Automatically run VSCode Extensions in Che workspaces](https://eclipse.dev/che/docs/stable/end-user-guide/microsoft-visual-studio-code-open-source-ide/#automating-installation-of-microsoft-visual-studio-code-extensions-at-workspace-startup)
- [Starting a workspace from a Git repository URL](https://eclipse.dev/che/docs/stable/end-user-guide/starting-a-workspace-from-a-git-repository-url/)
- [Making a workspace portable using a devfile](https://eclipse.dev/che/docs/stable/end-user-guide/devfile-introduction/)
- [Configure your instance of Che](https://eclipse.dev/che/docs/stable/administration-guide/checluster-custom-resource-fields-reference/) using the [CheCluster Kubernetes Custom Resource](https://doc.crds.dev/github.com/eclipse-che/che-operator)
- [Use and customize the embedded VSCode extensions registry](https://eclipse.dev/che/docs/stable/administration-guide/extensions-for-microsoft-visual-studio-code-open-source/#adding-or-removing-extensions-in-the-embedded-open-vsx-registry-instance)

### Feedback and Community
We love to hear from users and developers. Here are the various ways to get in touch with us:
* **Support:** You can ask questions, report bugs, and request features using [GitHub issues](https://github.com/eclipse/che/issues).
* **Public Chat:** Join the public [eclipse-che](https://communityinviter.com/apps/ecd-tools/join-the-community) Slack channel to discuss with community and contributors.
* **Twitter:** [@eclipse_che](https://twitter.com/eclipse_che)
* **Mailing List:** [che-dev@eclipse.org](https://accounts.eclipse.org/mailing-list/che-dev)
* **Weekly Meetings:** Join us in our [Che community meeting](https://github.com/eclipse/che/wiki/Che-Dev-Meetings) every second monday.


### Contributing
If you are interested in fixing issues and contributing directly to the code base:
- :bug: [Submitting bugs](https://github.com/eclipse/che/issues/new/choose)
- :page_facing_up: [Contributor license agreement](https://github.com/eclipse/che/wiki/Eclipse-Contributor-Agreement)
- :checkered_flag: [Development workflows](./CONTRIBUTING.md)
- :pencil: [Improve docs](https://github.com/eclipse-che/che-docs)
- :building_construction: [Che architecture](https://eclipse.dev/che/docs/stable/administration-guide/architecture-overview/)
- :octocat: [Che repositories](./CONTRIBUTING.md#other-che-repositories)
- :sparkles: [Good first issue for new contributors](https://github.com/eclipse/che/wiki/Labels#new-contributors)


#### Extending Eclipse Che
- [Customize the default dev tooling container (the universal developer image or UDI).](https://github.com/devfile/developer-images/)
- [Customize the list of getting started samples.](https://eclipse.dev/che/docs/stable/administration-guide/configuring-getting-started-samples/)
- [Add your own editor definition.](https://github.com/eclipse-che/che-plugin-registry/blob/main/che-editors.yaml)

### Roadmap
We maintain the [Che roadmap](https://github.com/eclipse/che/wiki/Roadmap) in the open way. We welcome anyone to ask question and contribute to the roadmap by joining our [community meetings](https://github.com/eclipse/che/wiki/Che-Dev-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`)

# Module for launch E2E tests related to Che 7

## 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=<username>`
    - `export TS_SELENIUM_OCP_PASSWORD=<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:
    ```
    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:**

- Deploy Che on Kubernetes infrastructure by using 'Minikube' and 'Chectl' <https://github.com/eclipse-che/che-server/blob/HEAD/deploy/kubernetes/README.md>
- Create workspace by using 'Chectl' and devfile
    - link to 'Chectl' manual <https://github.com/che-incubator/chectl#chectl-workspacestart>
    - link to devfile ( **`For successfull test passing, exactly provided devfile should be used`** ) <https://gist.githubusercontent.com/Ohrimenko1988/93f5426f4ebc1705c55feb8ff0396a49/raw/cbea89ad145ba33ed34a151a12c50f045f9f3b78/yaml-ls-bug.yaml>
- Provide the **`'TS_SELENIUM_BASE_URL'`** environment variable as described above
- export TS_SELENIUM_HAPPY_PATH_WORKSPACE_NAME=EmptyWorkspace (default value, see BASE_TEST_CONSTANTS.ts)
- perform command **`export USERSTORY=$TS_SELENIUM_HAPPY_PATH_WORKSPACE_NAME && npm run test-all-devfiles`**

## 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.
```
-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:
```
./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!
```
./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 `<username><increment>`. To use that approach set those parameters:
```
-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 `<username>-<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 ---
- Files Extracted: 5
- Estimated Token Budget: ~4510 tokens
- Canonical Reference: https://codewiki.google/github.com/eclipse-che/che
