|
1 | 1 | # Releasing |
2 | 2 |
|
3 | | -This guide describes the process of releasing osbuild and osbuild-composer to [upstream][upstream-git], into [Fedora][fedora-distgit] and [CentOS Stream][centos-distgit]. |
| 3 | +This guide describes the release pipeline for our RPM components, from upstream GitHub repositories through to downstream distributions. The pipeline is largely automated and flows through three main stages: **Upstream**, **Fedora**, and **CentOS Stream / RHEL**. |
4 | 4 |
|
5 | | -## Clone the release helpers |
| 5 | +## Components |
6 | 6 |
|
7 | | -Go to the [maintainer-tools repository][maintainer-tools], clone the repository and run `pip install -r requirements.txt` in order to get all the dependencies to be able to execute the `release.py` and `update-distgit.py` scripts. |
| 7 | +The following components are managed by this pipeline. All are released to Fedora, while some are also released to CentOS Stream, RHEL, or both: |
8 | 8 |
|
9 | | -It's also advised to set a GitHub personal access token, otherwise you might run into API usage quotas. Go to [Personal access tokens][github-token] on GitHub and create a new token with scope `public_repo`. Now, create a new packit user configuration at `~/.config/packit.yaml` and paste there the following content: |
10 | | - |
11 | | -``` |
12 | | -authentication: |
13 | | - github.com: |
14 | | - token: [YOUR_GITHUB_PERSONAL_ACCESS_TOKEN] |
15 | | -``` |
| 9 | +- [cockpit-image-builder](https://github.com/osbuild/image-builder-frontend) (Fedora, CentOS Stream / RHEL) |
| 10 | +- [image-builder](https://github.com/osbuild/image-builder-cli) (Fedora, CentOS Stream / RHEL) |
| 11 | +- [koji-image-builder](https://github.com/osbuild/koji-image-builder) (Fedora) |
| 12 | +- [koji-osbuild](https://github.com/osbuild/koji-osbuild) (Fedora) |
| 13 | +- [osbuild-composer](https://github.com/osbuild/osbuild-composer) (Fedora, CentOS Stream / RHEL) |
| 14 | +- [osbuild](https://github.com/osbuild/osbuild) (Fedora, CentOS Stream / RHEL) |
16 | 15 |
|
17 | 16 | ## Upstream release |
18 | 17 |
|
19 | | -Note: [Upstream releases are done automatically][upstream-release] on a fortnightly alternating schedule, meaning one week we release osbuild and then the next week we release osbuild-composer. |
20 | | - |
21 | | -### Manual upstream release |
22 | | - |
23 | | -Navigate to your local repository in your terminal and call the `release.py` script. It will interactively take you through the following steps: |
| 18 | +Upstream releases are driven by the [release-action][release-action] GitHub Action. Most components (`osbuild`, `osbuild-composer`, `image-builder`) are released on a **regular schedule every Wednesday**, with different components on different weeks. Other components (`cockpit-image-builder`, `koji-osbuild`, `koji-image-builder`) are released **ad-hoc** — manually triggered when needed. |
24 | 19 |
|
25 | | -1. Gather all pull request titles merged to `main` since the latest release tag |
26 | | -2. Create a draft of the next release tag |
| 20 | +1. **Push a new release tag** — The release-action creates and pushes a new `vXX` release tag to the upstream repository. If no new commits have been merged since the previous release, the action skips and no release is created. |
| 21 | +2. **Create the release and bump the version** — Once the tag is pushed, the release-action creates the GitHub release and bumps the version in the repository. This includes bumping the version in all relevant files — such as the SPEC file for components shipped as RPMs. The version bump prepares the repository for the next release and ensures that testing and development builds have a higher version than the most recent stable release. |
27 | 22 |
|
28 | | - While writing the commit message, keep in mind that it needs to conform to both Markdown and git commit message formats, have a look at the commit message for one of the [recent releases][recent-releases] to get a clear idea how it should look like. |
29 | | -3. Push your signed git tag to `main` |
30 | | - |
31 | | -From here on a [GitHub composite action][github-action] will take over and |
32 | | - |
33 | | -1. Create a GitHub release based on the tag (version and message) |
34 | | -2. Bump the version in `osbuild.spec` or `osbuild-composer.spec` (and potentially `setup.py`) |
35 | | -3. Commit and push this change to `main` so the version is already reflecting the next release |
| 23 | +:::tip |
| 24 | +A release can also be triggered manually at any time by running the release-action workflow from the GitHub Actions UI in the respective component repository. |
| 25 | +::: |
36 | 26 |
|
37 | 27 | ## Fedora release |
38 | 28 |
|
39 | | -We use packit (see `.packit.yml` in the osbuild or osbuild-composer repository respectively or the [official packit documentation][packit-dev]) to automatically push new releases directly to [Fedora's dist-git][fedora-distgit]. |
40 | | - |
41 | | -Then our [fedora-bot][fedora-bot] takes over and performs the remaining steps: |
| 29 | +Once a new upstream release is published, [Packit][packit-dev] takes over to push it into Fedora. |
42 | 30 |
|
43 | | -1. Get a kerberos ticket by running `kinit $USER@FEDORAPROJECT.ORG` |
44 | | -2. Call `fedpkg build` to schedule Koji builds for each active Fedora release (or: dist-git branch) |
45 | | -3. Update [Bodhi][bodhi] with the latest release |
| 31 | +1. **Open a PR for `fedora-all`** — Packit automatically opens a pull request with the new release against all active Fedora dist-git branches for each component. |
| 32 | +2. **Trigger a Koji build** — Once the PR is merged to dist-git, Packit triggers a [Koji][koji] build for all Fedora branches. |
| 33 | +3. **Submit a Bodhi update** — After the Koji build finishes, Packit submits a [Bodhi][bodhi] update targeting `fedora-stable`. |
46 | 34 |
|
47 | 35 | ## CentOS Stream / RHEL releases |
48 | 36 |
|
49 | 37 | If you are a Red Hat employee, please continue reading about this in our internal release guide. |
50 | 38 |
|
51 | | -## Spreading the word on osbuild.org |
| 39 | +## Key automation actors |
52 | 40 |
|
53 | | -The last of releasing a new version is to create a new post on osbuild.org. Just open a PR in [osbuild/osbuild.github.io]. You can find a lot of inspiration in existing release posts. |
| 41 | +| Actor | Role | |
| 42 | +| :---- | :--- | |
| 43 | +| [GitHub Actions (release-action)][release-action] | Creates upstream release tags and releases (scheduled or manually triggered) | |
| 44 | +| [Packit][packit-dev] | Manages Fedora dist-git PRs, Koji builds, and Bodhi updates | |
54 | 45 |
|
55 | | -[upstream-git]: https://github.com/osbuild/osbuild |
56 | | -[fedora-distgit]: https://src.fedoraproject.org/rpms/osbuild |
57 | | -[centos-distgit]: https://gitlab.com/redhat/centos-stream/rpms/osbuild |
58 | | -[maintainer-tools]: https://github.com/osbuild/maintainer-tools |
59 | | -[github-token]: https://github.com/settings/tokens |
60 | | -[github-action]: https://github.com/osbuild/release-action |
| 46 | +[release-action]: https://github.com/osbuild/release-action |
61 | 47 | [packit-dev]: https://packit.dev/docs/ |
62 | | -[osbuild/osbuild.github.io]: https://github.com/osbuild/osbuild.github.io |
63 | 48 | [koji]: https://koji.fedoraproject.org |
64 | 49 | [bodhi]: https://bodhi.fedoraproject.org/ |
65 | | -[fedora-bot]: https://github.com/osbuild/fedora-bot |
66 | | -[recent-releases]: https://github.com/osbuild/osbuild-composer/tags |
67 | | -[upstream-release]: https://github.com/osbuild/release-action/tree/create-tag |
0 commit comments