-
Get push permission from @fbenoit to push applications
-
Get commit rights from @fbenoit to push community PRs
Currently all projects have automated release process, that consists of GitHub Actions workflow.
Additionally, release logic is mostly contained within make-release.sh file, which allows to perform the release outside of GitHub Actions framework, should the need for it arises.
For example, in the Che server repo, GitHub action release.yml runs the make-release.sh release script.
GitHub Actions release workflows can be run by any user with write access to the repo in which the workflow is located. They use repository secrets, such as Quay or Docker.io credentials, that are required by most of the release workflows. If run outside GitHub, authorized users will need to provide their own secrets.
The Che projects that are part of the release cycle are orchestrated into a single action: Orchestrate Overall Release, which runs make-release.sh.
The projects covered by this workflow release container images, NPM artifacts, or CLI binaries versioned 7.yy.0 every sprint:
| Phase | Project | Workflow Status | Quay Image or NPM Artifact |
|---|---|---|---|
| Phase 1 | che-code |  |
che-code |
| configbump |  |
configbump | |
| che-machine-exec |  |
che-machine-exec | |
| che server |  |
che-server | |
| devworkspace-generator |  |
NPM @eclipse-che/che-devworkspace-generator | |
| kubernetes-image-puller |  |
kubernetes-image-puller/branches | |
| Phase 2 | che-e2e |  |
che-e2e |
| che-plugin-registry |  |
che-plugin-registry | |
| che-dashboard |  |
che-dashboard | |
| Phase 3 | che-devfile-registry |  |
che-devfile-registry |
| Phase 4 | che-operator |  |
che-operator |
Che Operator requires PR checks and manual approvals. When everything has been verified, and the PRs generated in the previous step are merged, the following workflows will be triggered.
| Phase | Project | Workflow Status | Other Artifact |
|---|---|---|---|
| Phase 5 | community-operator |  |
create pull requests to update to latest released version of Che in OperatorHub |
| chectl |  |
CLI tarballs | |
| che-docs |  |
tag and pull request to update to latest Che |
Notifications can be seen in the ECD Slack, across the following channels.
/github subscribe che-incubator/chectl releases workflows:{event:"workflow_dispatch","push" branch:"main"}
/github unsubscribe che-incubator/chectl issues pulls commits deployments branches
/github subscribe eclipse-che/che-operator workflows:{event:"workflow_dispatch","push" branch:"main"}
/github unsubscribe eclipse-che/che-operator issues pulls commits releases deployments branches
/github subscribe eclipse-che/che-release workflows:{event:"workflow_dispatch","push" branch:"main"}
/github unsubscribe eclipse-che/che-release issues pulls commits releases deployments branches
/github subscribe eclipse/che issues releases +label:'status/need-triage'
/github unsubscribe eclipse/che pulls commits deployments branches
/github subscribe list features
/github subscribe eclipse/che issues releases +label:'status/need-triage'
/github unsubscribe eclipse/che pulls commits deployments branches
/github subscribe list features
See #forum-che
The Release - Orchestrate Overall Release Phases action runs make-release.sh to release the various Che containers and packages in the correct order. This ensures that dependencies between containers or packages can be met. See make-release.sh for these dependencies. The list of phases is above.
-
Original procedure was to create new release issue to report status and collect any blocking issues, however the issue was usually empty since problems are resolved via Mattermost and Slack so communication is done there.
-
To start a release, use the Release - Orchestrate Overall Release Phases workflow to trigger workflows in other Che repos. Workflows triggered align to the repos noted in the previous section. In the input, provide the version of Che, and phases to run.
2.1 If one of the workflows has crashed, inspect it. Apply fixes if needed, and restart it. You can restart individual workflow, or whole phase in orchestration job, whichever is simpler.
2.2 Keep in mind, that sometimes you'll need to regenerate tags, or skip certain substeps in that job. Also ensure that correct code is in place, whether it is main or bugfix branch.
2.3 Sometimes, the hotfix changes to the workflow can take too long to get approved and merged. In certain situations, we can use the modified workflow file, which is pushed in its own branch, and then trigger the workflow, while specifying the branch with our modified workflow.
-
When Che Operator PRs have been generated, you must wait for the approval of PR checks, that are in that repository. If there are any questions, you can forward them to the check maintaners (Deploy team). When PRs are merged, the last batch of projects will be triggered to release
3.1 Chectl PR has to be closed manually, after they're generated, and all its associated PR checks are passed.
3.2 Community operator PRs are merged by Operator Framework members, as soon as their tests will pass (in some cases they may require some input from us)
3.3 Docs PR has to be merged by Docs team.
-
When the release is complete, an e-mail should be sent to the
che-devmailing list. -
TODO: a Slack notification should be sent to the ECD Slack. See eclipse-che/che#22551