Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated release operator workflow #1171

Merged
merged 2 commits into from
Mar 4, 2025
Merged

Automated release operator workflow #1171

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
33fc824
[ci] Automated release operator workflow
didierofrivia Feb 20, 2025
5fbc236
[docs] Updating RELEASE.md including automated release
didierofrivia Feb 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
138 changes: 138 additions & 0 deletions .github/workflows/automated-release.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,138 @@
name: Automated Release Operator

on:
workflow_dispatch:
inputs:
gitRef:
description: Commit SHA, tag or branch name (usually main branch)
required: true
default: "main"
type: string
kuadrantOperatorVersion:
description: Kuadrant Operator version (semver)
default: 0.0.0
type: string
authorinoOperatorVersion:
description: Authorino Operator bundle version (semver)
default: 0.0.0
type: string
limitadorOperatorVersion:
description: Limitador Operator bundle version (semver)
default: 0.0.0
type: string
dnsOperatorVersion:
description: DNS Operator bundle version (semver)
default: 0.0.0
type: string
wasmShimVersion:
description: WASM Shim version (semver)
default: 0.0.0
type: string
consolePluginVersion:
description: ConsolePlugin version (semver)
default: 0.0.0
type: string
olmChannel:
description: OLM channel
required: false
type: string
default: "stable"

jobs:
auto-release:
name: Release operator
runs-on: ubuntu-latest
steps:
- name: Set up Go 1.22.x
uses: actions/setup-go@v4
with:
go-version: 1.22.x
id: go
- name: Checkout code at git ref
uses: actions/checkout@v4
with:
ref: ${{ github.event.inputs.gitRef }}
token: ${{ secrets.KUADRANT_DEV_PAT }}

- name: Install gettext-base
run: |
sudo apt-get update
sudo apt-get install -y gettext-base

- name: Install yq tool
run: |
make yq

- name: Create release branch(es)
id: create-release-branch
shell: bash
run: |
base_branch=release-v$(echo "${{ github.event.inputs.kuadrantOperatorVersion }}" | sed 's/[+-].*//; s/\.[0-9]*$//')
echo BASE_BRANCH=$base_branch >> $GITHUB_ENV

if git ls-remote --exit-code --heads origin $base_branch ; then
echo "Base branch $base_branch already exists"
else
echo Creating branch "$base_branch"
git checkout -b "$base_branch"
git push origin
fi

- name: Prepare release
id: prepare-release
run: |
echo "Updating release.yaml with desired versions"

VERSION=${{ github.event.inputs.kuadrantOperatorVersion }} \
AUTHORINO_OPERATOR_VERSION=${{ github.event.inputs.authorinoOperatorVersion }} \
DNS_OPERATOR_VERSION=${{ github.event.inputs.dnsOperatorVersion }} \
LIMITADOR_OPERATOR_VERSION=${{ github.event.inputs.limitadorOperatorVersion }} \
CONSOLE_PLUGIN_VERSION=${{ github.event.inputs.consolePluginVersion }} \
WASM_SHIM_VERSION=${{ github.event.inputs.wasmShimVersion }} \
OLM_CHANNEL=${{ github.event.inputs.olmChannel }} \
yq eval '(.kuadrant-operator.version = strenv(VERSION)) |
(.dependencies.authorino-operator = strenv(AUTHORINO_OPERATOR_VERSION)) |
(.dependencies.dns-operator = strenv(DNS_OPERATOR_VERSION)) |
(.dependencies.limitador-operator = strenv(LIMITADOR_OPERATOR_VERSION)) |
(.dependencies.console-plugin = strenv(CONSOLE_PLUGIN_VERSION)) |
(.dependencies.wasm-shim = strenv(WASM_SHIM_VERSION)) |
(.olm.default-channel = strenv(OLM_CHANNEL)) |
(.olm.channels[0] = strenv(OLM_CHANNEL))' --inplace ./release.yaml

echo "release.yaml file updated as follows:"

cat ./release.yaml

echo "Running prepare-release script"

make prepare-release

- name: Create Pull Request
id: cpr
if: ${{ !env.ACT }}
uses: peter-evans/create-pull-request@v7
with:
token: ${{ secrets.KUADRANT_DEV_PAT }}
commit-message: Prepare release ${{ github.event.inputs.kuadrantOperatorVersion }}
committer: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
author: ${{ github.actor }} <${{ github.actor_id }}+${{ github.actor }}@users.noreply.github.com>
signoff: true
base: ${{ env.BASE_BRANCH }}
branch: release-v${{ github.event.inputs.kuadrantOperatorVersion }}
delete-branch: true
title: '[Release] Kuadrant Operator v${{ github.event.inputs.kuadrantOperatorVersion }}'
body: |
The following PR for the release candidate of Kuadrant Operator version ${{ github.event.inputs.kuadrantOperatorVersion }} includes:
- Authorino Operator version ${{ github.event.inputs.authorinoOperatorVersion }}
- DNS Operator version ${{ github.event.inputs.dnsOperatorVersion }}
- Limitador Operator version ${{ github.event.inputs.limitadorOperatorVersion }}
- Console Plugin version ${{ github.event.inputs.consolePluginVersion }}
- WASM Shim version ${{ github.event.inputs.wasmShimVersion }}

Auto-generated by [create-pull-request][1]

[1]: https://github.com/peter-evans/create-pull-request
team-reviewers: |
Kuadrant/developers
Kuadrant/qe
draft: false
86 changes: 50 additions & 36 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,42 +1,37 @@
# How to release Kuadrant Operator

## Kuadrant Operator Release

To release a version _“v0.W.Z”_ of Kuadrant Operator in GitHub and Quay.io, follow these steps:

### Release file format.
This example of the `release.yaml` file uses tag `v1.0.1` as reference.

```yaml
# FILE: ./release.yaml
kuadrant:
release: "1.0.1"
olm:
channels:
- "alpha"
default_channel: "alpha"
dependencies:
Authorino: "0.16.0"
Console_plugin: "0.0.14"
DNS: "0.12.0"
Limitador: "0.12.1"
Wasm_shim: "0.8.1"
```
The `kuadrant` section relates to the release version of the kuadrant operator.
While the `olm` section relates to fields required for building the olm catalogs.
And the `dependencies` section relates to the released versions of the subcomponents that will be included in a release.
There are validation steps during the `make prepare-release` that require the dependencies to be release before generating the release of the Kuadrant operator.

To release a version _“vX.Y.Z”_ of Kuadrant Operator in GitHub and Quay.io, there are two options, a manual and an automated process.
For both processes, first make sure every [Kuadrant Operator dependency](https://github.com/Kuadrant/kuadrant-operator/blob/main/RELEASE.md#kuadrant-operator-dependencies) has been already released.

## Automated Workflow

1. Run the GHA [Automated Release](https://github.com/Kuadrant/kuadrant-operator/actions/workflows/automated-release.yaml)
filling the following fields:
- gitRef: Select the branch/tag/commit where you want to cut a release from.
- kuadrantOperatorVersion: the [Semantic Version](https://semver.org/) of the desired release.
- authorinoOperatorVersion: Authorino Operator bundle version (X.Y.Z)
- limitadorOperatorVersion: Limitador Operator bundle version (X.Y.Z)
- dnsOperatorVersion: DNS Operator bundle version (X.Y.Z)
- wasmShimVersion: WASM Shim version (X.Y.Z)
- consolePluginVersion: ConsolePlugin version (X.Y.Z)
- olmChannel: This will set the OLM `channels` and `default-channel` annotations
2. The workflow will create a Pull Request that should be peer-reviewed and approved by a member of the Kuadrant team, focusing on the changes made in Kustomize config, OLM bundles and Helm Charts.
3. Once the PR is merged, a release workflow will be triggered tagging and publishing the [Github release](https://github.com/Kuadrant/kuadrant-operator/releases)
it will also build the images and packages and publish them on Quay, Helm repository.

### Notes
* It's not possible to cherry-pick commits, the workflow will pick a branch/tag/commit and all the history behind to the PR.
Comment on lines +22 to +23
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This related to this, would also affect the manual approach.

The PR is opened with the changes from the prepare-release, and some thing is missing from the release, lets say missing commit from main. That missing commit can be cherry picked to the branch which is the base targeting the release branch.

What should happen in that case? I am assuming the history of the base branch should be reordered to have the cherry picked commit before the release commit. The same would go for if during the review a wrong version is noticed. Would that be adding in a new commit or the release commit edited?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically any change in the history of the branch could be done in the PR, manually.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That I understand. The question would be should the history be reordered to ensure the Prepare release commit is the head of the branch?


## Manual Workflow

### Local steps

1. Create the `release-vX.Y` branch, if the branch does not already exist.
2. Push the `release-vX.Y` to the remote (kuadrant/kuadrant-operator)
3. Create the `release-vX.Y.Z-rc(n)` branch with `release-vX.Y` as the base.
4. Cherry-pick commits to the `kudrant-vX.Y.Z-rc(n)` from the relevant sources, i.e. `main`.
5. Update the applicable version in the `release.yaml`.
6. Run `make prepare-release` on the `release-vX.Y.Z-rc(n)`

5. Update the applicable version in the [release.yaml](https://github.com/Kuadrant/kuadrant-operator/blob/main/RELEASE.md#release-file-format).
6. Run `make prepare-release` on the `release-vX.Y.Z-rc(n)`

### Remote steps

Expand All @@ -53,20 +48,39 @@ There are validation steps during the `make prepare-release` that require the de
* Creates tags
6. Verify that the build [release tag workflow](https://github.com/Kuadrant/kuadrant-operator/actions/workflows/build-images-for-tag-release.yaml) is triggered and completes for the new tag.

## Kuadrant Operator Dependencies
## Release file format.
This example of the `release.yaml` file uses tag `v1.0.1` as reference.

1. Release Kuadrant dependencies as required:
```yaml
# FILE: ./release.yaml
kuadrant-operator:
version: "1.0.1"
olm:
default-channel: "stable"
channels:
- "stable"
dependencies:
authorino-operator: "0.16.0"
console-plugin: "0.0.14"
dns-operator: "0.12.0"
limitador-operator: "0.12.1"
wasm-shim: "0.8.1"
```

The `kuadrant-operator` section relates to the release version of the kuadrant operator.
While the `olm` section relates to fields required for building the olm catalogs.
And the `dependencies` section relates to the released versions of the subcomponents that will be included in a release.
There are validation steps during the `make prepare-release` that require the dependencies to be release before generating the release of the Kuadrant operator.

## Kuadrant Operator Dependencies
* [Authorino Operator](https://github.com/Kuadrant/authorino-operator/blob/main/RELEASE.md).
* [Limitador Operator](https://github.com/Kuadrant/limitador-operator/blob/main/RELEASE.md).
* [DNS Operator](https://github.com/Kuadrant/dns-operator/blob/main/docs/RELEASE.md).
* [WASM Shim](https://github.com/Kuadrant/wasm-shim/).
* [Console Plugin](https://github.com/Kuadrant/kuadrant-console-plugin).

2. Update the `release.yaml` with the versions of required dependencies.



## Verification

### Verify OLM Deployment

1. Deploy the OLM catalog image following the [Deploy kuadrant operator using OLM](/doc/development.md#deploy-kuadrant-operator-using-olm) and providing the generated catalog image. For example:
Expand Down
Loading