From 9e11b860ec0c7a78edddb65704a61229317fbbb8 Mon Sep 17 00:00:00 2001 From: Hidde Beydals Date: Sat, 1 Jul 2023 00:05:36 +0200 Subject: [PATCH] Address release procedure review nits Signed-off-by: Hidde Beydals --- docs/release/procedure.md | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/docs/release/procedure.md b/docs/release/procedure.md index 1f586189..603ce785 100644 --- a/docs/release/procedure.md +++ b/docs/release/procedure.md @@ -23,6 +23,7 @@ clarification. * [Patch releases](#distribution-patch-releases) * [Release candidates](#distribution-release-candidates) - [Backport changes for patch releases](#backport-changes-for-patch-releases) + + [Manual backporting](#manual-backporting) ## General rules @@ -132,7 +133,7 @@ release. 7. Create `api/` and `` tags for the merge commit in `release/v1.2.x`. Ensure the tags are signed according to the [general - rules](#general-rules)., and push them to the remote repository. + rules](#general-rules), and push them to the remote repository. ```shell git switch release/v1.2.x @@ -186,7 +187,7 @@ release. 6. Create `api/` and `` tags for the merge commit in `release/v1.2.x`. Ensure the tags are signed according to the [general - rules](#general-rules)., and push them to the remote repository. + rules](#general-rules), and push them to the remote repository. ```shell git switch release/v1.2.x @@ -229,19 +230,24 @@ A preview release is a release that is not intended for production use, but rather to allow users to quickly test new features or an intended bug fix, and provide feedback. -Preview releases are made by triggering the release GitHub Actions workflow on +Preview releases are made by triggering the `release` GitHub Actions workflow on a specific Git branch. This workflow will build the container image, sign it -using Cosign, and push it to the registry. But does not require a Git tag, +using Cosign, and push it to the registry. But it does not require a Git tag, GitHub release, or a changelog entry. To create a preview release, follow the steps below. 1. Navigate to `https://github.com/fluxcd/-controller/actions/workflows/release.yml`. + 2. Click the `Run workflow` button. + 3. Select the branch to release from the `Branch` dropdown. + 4. The default values for the `image tag` (`preview`) should be correct, but can be changed if necessary. + 5. Click the green `Run workflow` button. + 6. The workflow will now run, and the container image will be pushed to the registry. Once the workflow has completed, the image reference will be available in the logs, and can be shared in the relevant issue or pull @@ -264,10 +270,10 @@ version in the `main` branch when a new controller version is released. release. 2. Create a "release series" branch for the next minor SemVer range, e.g., - `release/v1.2.x`, and push it to the remote repository. + `release/v2.2.x`, and push it to the remote repository. ```shell - git switch -c release/v1.2.x main + git switch -c release/v2.2.x main ``` 3. Prepare the required release notes for this release, see [release @@ -278,8 +284,8 @@ version in the `main` branch when a new controller version is released. rules](#general-rules), and push it to the remote repository. ```shell - git tag -s -m "v1.2.0" v1.2.0 - git push origin v1.2.0 + git tag -s -m "v2.2.0" v2.2.0 + git push origin v2.2.0 ``` 5. Confirm that the CI builds and releases the newly tagged version. @@ -293,19 +299,19 @@ version in the `main` branch when a new controller version is released. #### Distribution patch releases 1. Ensure everything to be included in the release is backported to the - "release series" branch (e.g., `release/v1.2.x`). If not, refer to the + "release series" branch (e.g., `release/v2.2.x`). If not, refer to the [backporting](#backport-changes-for-patch-releases) section. 2. Prepare the required release notes for this release, see [release notes](#distribution-release-notes) for more information. 3. Tag the release series branch with the SemVer version of the release, e.g., - `v1.2.1`. Ensure the tag is signed according to the [general + `v2.2.1`. Ensure the tag is signed according to the [general rules](#general-rules), and push it to the remote repository. ```shell - git tag -s -m "v1.2.1" v1.2.1 - git push origin v1.2.1 + git tag -s -m "v2.2.1" v2.2.1 + git push origin v2.2.1 ``` 4. Confirm that the CI builds and releases the newly tagged version. @@ -322,7 +328,7 @@ of the distribution. To create a first release candidate, follow the steps to create a [minor release](#distribution-minor-releases), but use the `rc.X` suffix for SemVer -version to release (e.g., `v1.2.0-rc.1`). +version to release (e.g., `v2.2.0-rc.1`). Once the release series branch is created, subsequent release candidates and the final (non-RC) release should follow the procedure for [patch controller