|
1 | 1 | # Operator Release |
2 | 2 |
|
3 | | -This document describes the release process for the operator |
| 3 | +## Automated Release Process |
4 | 4 |
|
5 | | -## Versioning |
| 5 | +Releases are fully automated via GitHub Actions. |
6 | 6 |
|
7 | | -Always consider what is the suitable version number to be released based on the [Operator upgrade manual](docs/operator-upgrades.md). |
| 7 | +### To Release a New Version: |
8 | 8 |
|
9 | | -## Release script |
| 9 | +1. Go to the repository's **Releases** page |
| 10 | +2. Select **Draft a new release** |
| 11 | +3. Select **Choose a tag** and type the new version (e.g., `v12.1.0`) |
| 12 | +4. Select **Create new tag: v12.1.0 on publish** |
| 13 | +5. Set the release title (e.g., `v12.1.0`) |
| 14 | +6. Optionally add release notes describing the changes |
| 15 | +7. Select **Publish release** |
10 | 16 |
|
11 | | -The `release.sh` script will generate/update the Helm chart files. |
| 17 | +The release workflow will automatically: |
| 18 | +- Update version in Chart.yaml and kustomization.yaml |
| 19 | +- Regenerate Helm chart and manifests |
| 20 | +- Commit changes to main |
| 21 | +- Move the tag to include version updates |
| 22 | +- Trigger container image builds (multi-arch) |
| 23 | +- Publish Helm chart to GitHub Pages and OCI registry |
| 24 | +- Update the GitHub release with manifest files |
12 | 25 |
|
13 | | -Ensure the following software is installed before running the release script: |
| 26 | +### Versioning |
14 | 27 |
|
15 | | -- `yq` |
16 | | -- `operator-sdk` |
| 28 | +Follow [semantic versioning](https://semver.org/): |
| 29 | +- **Patch** (12.0.X): Bug fixes, no breaking changes |
| 30 | +- **Minor** (12.X.0): New features, backwards compatible |
| 31 | +- **Major** (X.0.0): Breaking changes (see [upgrade docs](docs/operator-upgrades.md)) |
17 | 32 |
|
18 | | -Run the release script: |
| 33 | +### Pre-Releases |
19 | 34 |
|
20 | | -1. Run the `release.sh` script from the root of the mondoo-operator repo with the previous version of the operator as the first parameter and the new version of the operator as the second parameter (without any leading 'v' in the version string). For example: |
| 35 | +For alpha, beta, or release candidate versions: |
21 | 36 |
|
22 | | -```bash |
23 | | -$ ./release.sh 1.4.0 1.4.1 |
24 | | -``` |
| 37 | +1. Follow the same release process above |
| 38 | +2. Use semver pre-release format: `v12.1.0-alpha.1`, `v12.1.0-rc.1` |
| 39 | +3. **Check the "Set as a pre-release" checkbox** in GitHub Release UI |
25 | 40 |
|
26 | | -### Helm Chart and Operator bundle |
| 41 | +Pre-releases will: |
| 42 | +- Build and publish container images (tagged with the pre-release version) |
| 43 | +- Publish Helm chart (with pre-release version) |
| 44 | +- **NOT** update the "latest" Docker tag |
| 45 | +- **NOT** be marked as the latest GitHub release |
27 | 46 |
|
28 | | -Mondoo Operator helm chart has been auto-generated using the [helmify](https://github.com/arttor/helmify) tool via the `release.sh` script. The CI uses [chart-releaser-action](https://github.com/helm/chart-releaser-action) to self host the charts using GitHub pages. |
| 47 | +Users can deploy a specific pre-release by specifying the version explicitly. |
29 | 48 |
|
30 | | -The following steps need to be followed to release Helm chart. |
| 49 | +### Manual Release (Emergency) |
31 | 50 |
|
32 | | -#### Helm Chart Release Workflow |
| 51 | +If the automated workflow fails, you can release manually: |
33 | 52 |
|
34 | | -Helm chart release action is executed against release tags. It checks each chart in the charts folder, and whenever there's a new chart version, creates a corresponding GitHub release named for the chart version, adds Helm chart artifacts to the release, and creates or updates an index.yaml file with metadata about those releases, which is then hosted on GitHub Pages. |
| 53 | +1. Run the release script: |
| 54 | + ```bash |
| 55 | + ./release.sh <previous_version> <new_version> |
| 56 | + ``` |
35 | 57 |
|
36 | | -### Committing the release |
| 58 | +2. Create a PR with the changes |
37 | 59 |
|
38 | | -After running the `release.sh` script, you can create a pull request containing the changes made to the repo (mainly the files under ./charts and ./config. Once the pull request has merged, you need to tag the release. |
39 | | - |
40 | | -1. git checkout main |
41 | | -2. git pull |
42 | | -3. git tag v1.4.1 |
43 | | -4. git push origin v1.4.1 |
| 60 | +3. After merge, tag and push: |
| 61 | + ```bash |
| 62 | + git checkout main && git pull |
| 63 | + git tag v<new_version> |
| 64 | + git push origin v<new_version> |
| 65 | + ``` |
0 commit comments