Project: Eclipse Che (App Definition and Development / Application Definition & Image Build)
File: CONTRIBUTING.md

- Che is composed of multiple sub projects. For each projects we provide a CONTRIBUTE.md file describing how to setup the development environment to start your contribution. Most of the time, we encourage you to use Che to contribute to Che. If creating a new repo under the or organizations, you may need to upload a secret to enable GH actions and workflow automation. You can do so using . If using an existing secret, for example to enable the che-bot or che-incubator-bot, contact someone on the Che development team to get access to the current secret or token you need to upload. <!-- begin repository list --> Repository | Component | Description | Devfile | Documentation | | | | | | (this repository) the main project repository | | | | source code of our integration tests. | | | | | Che server project repository | | | | source code, dockerfiles to build our main docker images. Note that Che-code related dockerfiles are located in che-code repo. | | | | | orchestrates the Che workspaces with devfiles on Kubernetes | | | | | source code of our integration tests. | | | | | The CLI to install Che, create and start workspaces and devfiles | | | | Fork of "Code - OSS" to work with Eclipse Che | | | | UI to manage workspaces, devfiles, etc. | | | | The default set of devfiles that would be made available on the Che dashboard stacks. | | | | Eclipse Che documentation https://github.com/eclipse-che/che-docs source code. | | | | Interface to execute tasks and terminals on other containers within a workspace. | | | | Che operator to deploy, update and manage K8S/OpenShift resources of Che. | | | | The default set of Che plugins (vscode extension + containers) or editors that could be installed on any Che workspaces. | | | | https://eclipse.dev/che website source code. | | | | JS library to interact with a che-server. | | | | Simple Kubernetes controller that is able to quickly synchronize a set of config maps | | | | Provides the ability to increase I/O performance for a developer workspaces | | | | abstract telemetry API and a Typescript implementation of the API. | | | | ensures that all nodes in the cluster have those images cached | | | | Eclispe Che blog content. Get published at https://che.eclipseprojects.io/ | | | | Vale style for Eclipse Che Documentation and related projects | | | | orchestration scripts for Eclipse Che artifacts and container images. | | | | GitHub action deploying Eclipse Che using chectl | | | | Allow to convert Devfile v1 to v2 or v2 to v1 | | | | Run Happy Path tests as part of a Github action | | | | Traefik plugin that can modify http

| | | | Run JetBrains IDE remotely in Eclipse Che | | | | Install, configure, and manage the kubernetes-image-puller | | | | Runs devfile based development environments on Kubernetes | | | | Upstream devfile registry | | | | Container images to code, build run applications on secured Kubernetes clusters | | | | DevWorkspace operator documentation | | | | License header format checker | | | | Devworkspace telemetry Woopra plugin | | | | Github action for starting Minikube to be able to Install/Run Eclipse Che | | | | Github action to check file with list golang runtime dependencies and license information. | | | | A container wrapper for The Eclipse Dash License Tool. | | | | Devfile API library | | <!-- end repository list --> We are trying to provide a devfile for each areas where you could contribute. Each devfile could be run on any Che instances to setup a ready-to-code developer environment. Beware that each of them may need a certain amount of memory. Devfile could be launched through a factory or cli. ```bash $ chectl workspace:start -f devfiles/che-theia-all.devfile.yaml ``` or ```bash $ chectl workspace:start -f https://raw.githubusercontent.com/eclipse/che-theia/main/devfiles/che-theia-all.devfile.yaml ``` or `https://<CheInstance>/f?url=https://raw.githubusercontent.com/eclipse/che-theia/main/devfiles/che-theia-all.devfile.yaml` Let's cover the developer flow for these projects: There is a for development of Che server in Che. To build Che one may run a predefined build task from the devfile. Starting Che master requires some manual steps. Open a terminal in runtime container (`che-server-runtime`) and perform: First, set `CHE_HOME` environment variable with absolute path to parent folder of Che master's Tomcat. It might look like `/projects/che/assembly/assembly-main/target/eclipse-che--SNAPSHOT/eclipse-che--SNAPSHOT`. Then set `CHE_HOST` with the endpoint of new Che master. If using the the endpoint is `che-dev` and already set. After, set `CHEINFRASTRUCTUREACTIVE` according to your environment. For example: `openshift` (note, use `kubernetes` and `openshift` insted of `minikube` and `minishift` correspondingly). Run `/entrypoint.sh`. After this, new Che master should be accesible from the `che-dev` endpoint. To reach Swagger use url from `che-dev` endpoint with `/swagger` suffix. To start a workspace from Che server under development some additional configuration of the cluster is needed. One should add rights for the service account to be able to perform all needed for Che server actions. Example for Openshift (in case of Kubernetes replace `oc` with `kubectl`): ```bash cat << EOF | oc apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: labels: app: che component: che name: che-workspace-admin namespace: che roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin subjects: kind: ServiceAccount name: che-workspace namespace: che EOF ``` Also `CHEAPIINTERNAL`, `CHEAPIEXTERNAL` and `CHE_API` should be set in runner container and point to new Che server API. If one uses provided devfile, they are already set to: `http://che-dev:8080/api`, which should be changed in case of https protocol. Che repositories includes a GitHub Pull Request Template. Contributors must read and complete the template. In particular there is a list of requirements that the author needs to fulfil to merge the PR. This sections goes into the details of this checklist. The author has completed the and has signed the commits using his email. No `TODO` comments left in the PR source code. The author has verified that code builds, tests pass and linters are happy. If the Pull Request fixes a bug, it must includes a new automated test. The test validates the fix and protect against future regressions. If the Pull Request is for a new feature, it must include a new automated test. The test(s) validate the feature and protect against future regressions. The devfile commands used to build and run the application are still