From f0ee035999a8c71ccc6dcfa0bdfa074aa075f2c5 Mon Sep 17 00:00:00 2001 From: Stefan Bueringer Date: Fri, 4 Nov 2022 14:35:12 +0100 Subject: [PATCH] Add release tasks doc and corresponding issue template --- .github/ISSUE_TEMPLATE/bug_report.md | 6 +- .github/ISSUE_TEMPLATE/feature_request.md | 5 +- .github/ISSUE_TEMPLATE/release_tracking.md | 80 ++++ CONTRIBUTING.md | 2 +- docs/developer/release-cycle.md | 113 ----- docs/developer/releasing.md | 61 --- docs/release/release-1.3.md | 27 ++ docs/release/release-1.4.md | 35 ++ .../release-cycle-overview.png | Bin docs/release/release-cycle.md | 52 +++ docs/release/release-tasks.md | 408 ++++++++++++++++++ docs/{developer => release}/release-team.md | 6 +- hack/verify-doctoc.sh | 2 +- 13 files changed, 616 insertions(+), 181 deletions(-) create mode 100644 .github/ISSUE_TEMPLATE/release_tracking.md delete mode 100644 docs/developer/release-cycle.md delete mode 100644 docs/developer/releasing.md create mode 100644 docs/release/release-1.3.md create mode 100644 docs/release/release-1.4.md rename docs/{developer => release}/release-cycle-overview.png (100%) create mode 100644 docs/release/release-cycle.md create mode 100644 docs/release/release-tasks.md rename docs/{developer => release}/release-team.md (94%) diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 98a488626a25..3362f30470f3 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -1,6 +1,9 @@ --- -name: Bug report +name: 🐛 Bug report about: Tell us about a problem you are experiencing +title: '' +labels: '' +assignees: '' --- @@ -24,4 +27,3 @@ about: Tell us about a problem you are experiencing /kind bug [One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels] - diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index 60aafc2a8716..7d19611b5116 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -1,6 +1,9 @@ --- -name: Feature request +name: ✨ Feature request about: Suggest an idea for this project +title: '' +labels: '' +assignees: '' --- diff --git a/.github/ISSUE_TEMPLATE/release_tracking.md b/.github/ISSUE_TEMPLATE/release_tracking.md new file mode 100644 index 000000000000..0c5e34b565ef --- /dev/null +++ b/.github/ISSUE_TEMPLATE/release_tracking.md @@ -0,0 +1,80 @@ +--- +name: 🚋 Release cycle tracking +about: Create a new release cycle tracking issue for a minor release +title: Tasks for v release cycle +labels: '' +assignees: '' + +--- + +Please see the corresponding section in [release-tasks.md](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md) for documentation of individual tasks. + +## Tasks + +**Notes**: +* Weeks are only specified to give some orientation. +* The following is based on the v1.4 release cycle. Modify according to the tracked release cycle. + +Week -3 to 1: +* [ ] [Release Lead] [Set a tentative release date for the minor release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#set-a-tentative-release-date-for-the-minor-release) +* [ ] [Release Lead] [Assemble release team](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#assemble-release-team) + +Week 1: +* [ ] [Release Lead] [Finalize release schedule and team](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#finalize-release-schedule-and-team) +* [ ] [Release Lead] [Prepare main branch for development of the new release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#prepare-main-branch-for-development-of-the-new-release) +* [ ] [Communications Manager] [Add docs to collect release notes for users and migration notes for provider implementers](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#add-docs-to-collect-release-notes-for-users-and-migration-notes-for-provider-implementers) +* [ ] [Communications Manager] [Update supported versions](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#update-supported-versions) + +Week 1 to 4: +* [ ] [Release Lead] [Track] [Remove previously deprecated code](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#track-remove-previously-deprecated-code) + +Week 6: +* [ ] [Release Lead] [Cut the v1.3.1 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) + +Week 9: +* [ ] [Release Lead] [Cut the v1.3.2 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) + +Week 11 to 12: +* [ ] [Release Lead] [Track] [Bump dependencies](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#track-bump-dependencies) + +Week 13: +* [ ] [Release Lead] [Cut the v1.4.0-beta.0 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) +* [ ] [Release Lead] [Cut the v1.3.3 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) +* [ ] [Release Lead] [Create a new GitHub milestone for the next release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#create-a-new-github-milestone-for-the-next-release) + +Week 14: +* [ ] [Release Lead] [Cut the v1.4.0-beta.1 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) +* [ ] [Release Lead] Select release lead for the next release cycle + +Week 15: +* [ ] [Release Lead] [Create the release-1.4 release branch](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#create-a-release-branch) +* [ ] [Release Lead] [Cut the v1.4.0-rc.0 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) +* [ ] [CI Manager] [Setup jobs and dashboards for the release-1.4 release branch](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#setup-jobs-and-dashboards-for-a-new-release-branch) +* [ ] [Communications Manager] [Ensure the book for the new release is available](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#ensure-the-book-for-the-new-release-is-available) + +Week 15 to 17: +* [ ] [Communications Manager] [Polish release notes](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#polish-release-notes) + +Week 16: +* [ ] [Release Lead] [Cut the v1.4.0-rc.1 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) + +Week 17: +* [ ] [Release Lead] [Cut the v1.4.0 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) +* [ ] [Release Lead] [Cut the v1.3.4 release](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#repeatedly-cut-a-release) +* [ ] [Release Lead] Organize release retrospective +* [ ] [Communications Manager] [Change production branch in Netlify to the new release branch](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#change-production-branch-in-netlify-to-the-new-release-branch) +* [ ] [Communications Manager] [Update clusterctl links in the quickstart](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#update-clusterctl-links-in-the-quickstart) + +Continuously: +* [Release lead] [Maintain the GitHub release milestone](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#continuously-maintain-the-github-release-milestone) +* [Communications Manager] [Communicate key dates to the community](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#continuously-communicate-key-dates-to-the-community) +* [Communications Manager] Improve release process documentation +* [Communications Manager] Maintain and improve user facing documentation about releases, release policy and release calendar +* [CI Manager] [Monitor CI signal](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#continuously-monitor-ci-signal) +* [CI Manager] [Reduce the amount of flaky tests](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#continuously-reduce-the-amount-of-flaky-tests) +* [CI Manager] [Bug triage](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#continuously-bug-triage) +* [CI Manager] Maintain and improve release automation, tooling & related developer docs + +If and when necessary: +* [ ] [Release Lead] [Track] [Bump the Cluster API apiVersion](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#optional-track-bump-the-cluster-api-apiversion) +* [ ] [Release Lead] [Track] [Bump the Kubernetes version](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-tasks.md#optional-track-bump-the-kubernetes-version) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5187a41feccf..26ee8cc7ef76 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -51,7 +51,7 @@ come up, including gaps in documentation! If you're a more experienced contributor, looking at unassigned issues in the next release milestone is a good way to find work that has been prioritized. For example, if the latest minor release is `v1.0`, the next release milestone is `v1.1`. -Help and contributions are very welcome in the form of code contributions but also in helping to moderate office hours, triaging issues, fixing/investigating flaky tests, being part of the [release team](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/developer/release-team.md), helping new contributors with their questions, reviewing proposals, etc. +Help and contributions are very welcome in the form of code contributions but also in helping to moderate office hours, triaging issues, fixing/investigating flaky tests, being part of the [release team](https://github.com/sbueringer/cluster-api/blob/pr-release-tasks/docs/release/release-team.md), helping new contributors with their questions, reviewing proposals, etc. ## Versioning diff --git a/docs/developer/release-cycle.md b/docs/developer/release-cycle.md deleted file mode 100644 index 5cbd1fc2b713..000000000000 --- a/docs/developer/release-cycle.md +++ /dev/null @@ -1,113 +0,0 @@ -# Release Cycle - -The release cycle is the time between when we start working on a release on the `main` branch until the `.0` release (e.g. `v1.3.0`) is released. - -**Note**: For the `v1.3` and `v1.4` releases we assume each release cycle will last approximately 4 months (~ 17 weeks). -The release cycle duration will be revisited after the `v1.4.0` release. - -A release cycle can be split up into the following phases: - -* Week 1-12: Active development - * All changes impacting providers' adoption of Cluster API should be implemented and merged in this period. Exceptions - require special approval as described in the section below. - * Alpha releases will be released based on the main branch only if necessary (to be determined by the release lead) - * Please note that we also publish daily releases based on the main branch. -* Week 13-14: Beta - * Weekly beta releases will be released based on the main branch - * The beta releases are meant as a preview of the upcoming release - * Providers can start adopting the new release based on the beta releases - * All changes that impact providers' adoption of the new release should be announced in the provider updates section - of the office hours meeting notes and approved in the PR or issue by both approvers and key affected providers. -* Week 15-16: RC - * The release branch is created - * Weekly RC releases will be released based on the release branch - * RC releases are as close as possible to the final release but they are still undergoing further testing - * Development of the next release can technically start on the main branch, but some changes might be delayed - to ensure easier cherry-picking of other changes to the release branch. - * There is a feature freeze on the release branch - * Only cherry-picks for documentation, bug fixes, test fixes and test additions are allowed -* Week 17: GA - * `x.y.0` GA release is created based on the release branch -* After that: - * **Note** The following is the responsibility of the release team of the following release cycle. - * `x.y.1+`: Monthly patch releases will be released based on the release branch - * Cherry-picks to the release branch are allowed according to the [backport policy](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#backporting-a-patch) - * Providers create releases using the new CAPI minor release when they are ready - * Development of the next release can now officially start on the main branch - -Some additional notes: - -* Support for new Kubernetes minor versions (for management and workload clusters) is first implemented - on the main branch, then cherry-picked into supported release branches when feasible and eventually - released in the next monthly patch release(s). - * **Note**: We usually don't have to bump Go dependencies to support new Kubernetes minor versions as it's not necessary - to run on a management cluster with the new version or create a workload cluster with the new version. - If it becomes necessary to bump dependencies to a new CR/Kubernetes minor version, the change cannot be cherry-picked - as bumping dependencies to a new minor version is a breaking change. -* New Kubernetes and Controller-Runtime (CR) minor releases are only picked up on the main branch. - -The following diagram visualizes the release cycles with the v1.2, v1.3 and v1.4 releases: - - -![Release Cycle Overview](release-cycle-overview.png) - -# v1.3 Release Cycle timeline - -**Note**: This release will be used to set up documentation, automation, etc. for the first release team which will start with -the `v1.4` release cycle. - -The following table shows the preliminary dates for the `v1.3` release cycle. - -| **What** | **When** | **Week** | -|------------------------------------------------------|-------------------------------|----------| -| Start of Release Cycle | Monday 18th July 2022 | week 1 | -| *1.2.1 released* | Monday 15th August 2022 | week 5 | -| *1.2.2 released* | Wednesday 14th September 2022 | week 9 | -| *1.2.3 released* | Monday 10th October 2022 | week 13 | -| *1.2.4 released* | Monday 17th October 2022 | week 14 | -| 1.3.0-beta.0 released | Tuesday 1st November 2022 | week 16 | -| 1.3.0-beta.1 released | Tuesday 8th November 2022 | week 17 | -| *1.2.5 released* | Tuesday 8th November 2022 | week 17 | -| release-1.3 branch created (**Begin [Code Freeze]**) | Tuesday 15th November 2022 | week 18 | -| release-1.3 jobs created | Tuesday 15th November 2022 | week 18 | -| 1.3.0-rc.0 released | Tuesday 15th November 2022 | week 18 | -| 1.3.0-rc.1 released | Tuesday 22nd November 2022 | week 19 | -| **1.3.0 released** | Thursday 1st December 2022 | week 20 | -| *1.2.6 released* | Thursday 1st December 2022 | week 20 | - -After the `.0` release monthly patch release will be created. - -# v1.4 Release Cycle timeline - -**Note**: The `v1.4` release will be the first release created by a dedicated release team. - -The following table shows the preliminary dates for the `v1.4` release cycle. - -| **What** | **Who** | **When** | **Week** | -|------------------------------------------------------|--------------|----------------------------|----------| -| Start of Release Cycle | Release Lead | Monday 5th December 2022 | week 1 | -| Schedule finalized | Release Lead | Friday 9th December 2022 | week 1 | -| Team finalized | Release Lead | Friday 9th December 2022 | week 1 | -| *1.3.1 released* | Release Lead | Tuesday 10th January 2023 | week 6 | -| *1.3.2 released* | Release Lead | Tuesday 31st January 2023 | week 9 | -| 1.4.0-beta.0 released | Release Lead | Tuesday 28th February 2023 | week 13 | -| *1.3.3 released* | Release Lead | Tuesday 28th February 2023 | week 13 | -| 1.4.0-beta.1 released | Release Lead | Tuesday 7th March 2023 | week 14 | -| release-1.4 branch created (**Begin [Code Freeze]**) | Release Lead | Tuesday 14th March 2023 | week 15 | -| release-1.4 jobs created | CI Manager | Tuesday 14th March 2023 | week 15 | -| 1.4.0-rc.0 released | Release Lead | Tuesday 14th March 2023 | week 15 | -| 1.4.0-rc.1 released | Release Lead | Tuesday 21st March 2023 | week 16 | -| **1.4.0 released** | Release Lead | Tuesday 28th March 2023 | week 17 | -| *1.3.4 released* | Release Lead | Tuesday 28th March 2023 | week 17 | -| Organize release retrospective | Release Lead | TBC | week 17 | - -## Release team - -TODO: This table should be filled once the release team has been finalized in ~ this -style: [Kubernetes 1.26 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.26/release-team.md) (I'm referring to the Name, Github, Slack ID pattern) - -| **Role** | **Lead Name** (**GitHub / Slack ID**) | **Shadow Name(s) (GitHub / Slack ID)** | -|-------------------------------------------|---------------------------------------|----------------------------------------| -| Release Lead | Yuvaraj Kakaraparthi ([@ykakarap](https://github.com/ykakarap)/Slack:`@Yuvaraj Kakaraparthi`) | Jim Ntosas ([@dntosas](https://github.com/dntosas)/ Slack:`@dntosas`), Carlos Panato ([@cpanato](https://github.com/cpanato)/ Slack:`@cpanato`), Amit Kumar ([@hackeramitkumar](https://github.com/hackeramitkumar)/ Slack:`@Amit Kumar`) | -| Communications/Docs/Release Notes Manager | Oscar Utbult ([@oscr](https://github.com/oscr)/ Slack:`@oscar`) | Sayantani Saha ([@sayantani11](https://github.com/sayantani11)/ Slack:`@sayantani`), Vibhor Chinda ([@VibhorChinda](https://github.com/VibhorChinda)/ Slack:`@Vibhor Chinda`) | -| CI Signal/Bug Triage/Automation Manager | Furkat Gofurov ([@furkatgofurov7](https://github.com/furkatgofurov7)/ Slack: `@Furkat Gofurov`) | Nawaz Khazielakha ([@nawazkh](https://github.com/nawazkh)/ Slack: `@nawaz`), Aniruddha Basak ([@aniruddha2000](https://github.com/aniruddha2000/)/ Slack: `@aniruddha`), Alexander Demicev ([@alexander-demicev](https://github.com/alexander-demicev)/ Slack:`@Alexander Demicev`) | diff --git a/docs/developer/releasing.md b/docs/developer/releasing.md deleted file mode 100644 index 7a0526aa992c..000000000000 --- a/docs/developer/releasing.md +++ /dev/null @@ -1,61 +0,0 @@ -# Release Process - -## Create a tag - -1. Create an annotated tag - > NOTE: To use your GPG signature when pushing the tag, use `git tag -s [...]` instead) - - `export RELEASE_TAG=` (eg. `export RELEASE_TAG=v1.0.1`) - - `git tag -a ${RELEASE_TAG} -m ${RELEASE_TAG}` - - `git tag test/${RELEASE_TAG}` (:warning: MUST NOT be an annotated tag) -1. Push the tag to the GitHub repository. This will automatically trigger a [Github Action](https://github.com/kubernetes-sigs/cluster-api/actions) to create a draft release. - > NOTE: `origin` should be the name of the remote pointing to `github.com/kubernetes-sigs/cluster-api` - - `git push origin ${RELEASE_TAG}` - - `git push origin test/${RELEASE_TAG}` - -## Promote images from the staging repo to `registry.k8s.io/cluster-api` - -Images are built by the [post push images job](https://testgrid.k8s.io/sig-cluster-lifecycle-image-pushes#post-cluster-api-push-images). This will push the image to a [staging repository](https://console.cloud.google.com/gcr/images/k8s-staging-cluster-api). - -1. If you don't have a GitHub token, create one by going to your GitHub settings, in [Personal access tokens](https://github.com/settings/tokens). Make sure you give the token the `repo` scope. -1. Wait for the above job to complete for the tag commit and for the image to exist in the staging repository, then create a PR to promote the image and tag: - - `export GITHUB_TOKEN=` - - `make promote-images` - -*Note*: `kpromo` uses `git@github.com:...` as remote to push the branch for the PR. If you don't have `ssh` set up you can configure - git to use `https` instead via `git config --global url."https://github.com/".insteadOf git@github.com:`. - -This will automatically create a PR in [k8s.io](https://github.com/kubernetes/k8s.io) and assign the CAPI maintainers. - -## Release in GitHub - -1. Review the draft release on GitHub. Pay close attention to the `## :question: Sort these by hand` section, as it contains items that need to be manually sorted. -1. Publish the release - -## Update Netlify for Cluster API book - -_Note: Only requried for new major and minor releases._ - -Get someone with Netlify access to do the following: - -1. Trigger `renew certificate` on Netlify UI. -1. Change production branch on Netlify UI to the newest release branch. -1. Trigger a re-deploy on Netlify UI for book to point to the new release-branch. - -## Homebrew - -1. Publish `clusterctl` to Homebrew by bumping the version in [clusterctl.rb](https://github.com/Homebrew/homebrew-core/blob/master/Formula/clusterctl.rb). - For an example please see: [PR: clusterctl 1.1.5](https://github.com/Homebrew/homebrew-core/pull/105075/files). - - **Note**: Homebrew has [conventions for commit messages](https://docs.brew.sh/Formula-Cookbook#commit) usually - the commit message for us should be e.g. "clusterctl 1.1.5" - -### Versioning - -See the [versioning documentation](./../../CONTRIBUTING.md#versioning) for more information. - -### Permissions - -Releasing requires a particular set of permissions. - -* Tag push access to the GitHub repository -* GitHub Release creation access diff --git a/docs/release/release-1.3.md b/docs/release/release-1.3.md new file mode 100644 index 000000000000..a55704db5c7d --- /dev/null +++ b/docs/release/release-1.3.md @@ -0,0 +1,27 @@ +# Cluster API v1.3 + +## Timeline + +**Note**: This release will be used to set up documentation, automation, etc. for the first release team which will start with +the `v1.4` release cycle. + +The following table shows the preliminary dates for the `v1.3` release cycle. + +| **What** | **When** | **Week** | +|------------------------------------------------------|-------------------------------|----------| +| Start of Release Cycle | Monday 18th July 2022 | week 1 | +| *v1.2.1 released* | Monday 15th August 2022 | week 5 | +| *v1.2.2 released* | Wednesday 14th September 2022 | week 9 | +| *v1.2.3 released* | Monday 10th October 2022 | week 13 | +| *v1.2.4 released* | Monday 17th October 2022 | week 14 | +| v1.3.0-beta.0 released | Tuesday 1st November 2022 | week 16 | +| v1.3.0-beta.1 released | Tuesday 8th November 2022 | week 17 | +| *v1.2.5 released* | Tuesday 8th November 2022 | week 17 | +| release-1.3 branch created (**Begin [Code Freeze]**) | Tuesday 15th November 2022 | week 18 | +| v1.3.0-rc.0 released | Tuesday 15th November 2022 | week 18 | +| release-1.3 jobs created | Tuesday 15th November 2022 | week 18 | +| v1.3.0-rc.1 released | Tuesday 22nd November 2022 | week 19 | +| **v1.3.0 released** | Thursday 1st December 2022 | week 20 | +| *v1.2.6 released* | Thursday 1st December 2022 | week 20 | + +After the `.0` release monthly patch release will be created. diff --git a/docs/release/release-1.4.md b/docs/release/release-1.4.md new file mode 100644 index 000000000000..b7633107ddc4 --- /dev/null +++ b/docs/release/release-1.4.md @@ -0,0 +1,35 @@ +# Cluster API v1.4 + +## Timeline + +**Note**: The `v1.4` release will be the first release created by a dedicated release team. + +The following table shows the preliminary dates for the `v1.4` release cycle. + +| **What** | **Who** | **When** | **Week** | +|------------------------------------------------------|--------------|----------------------------|----------| +| Start of Release Cycle | Release Lead | Monday 5th December 2022 | week 1 | +| Schedule finalized | Release Lead | Friday 9th December 2022 | week 1 | +| Team finalized | Release Lead | Friday 9th December 2022 | week 1 | +| *v1.2.7 & v1.3.1 released* | Release Lead | Tuesday 10th January 2023 | week 6 | +| *v1.2.8 & v1.3.2 released* | Release Lead | Tuesday 31st January 2023 | week 9 | +| v1.4.0-beta.0 released | Release Lead | Tuesday 28th February 2023 | week 13 | +| *v1.2.9 & v1.3.3 released* | Release Lead | Tuesday 28th February 2023 | week 13 | +| v1.4.0-beta.1 released | Release Lead | Tuesday 7th March 2023 | week 14 | +| release-1.4 branch created (**Begin [Code Freeze]**) | Release Lead | Tuesday 14th March 2023 | week 15 | +| v1.4.0-rc.0 released | Release Lead | Tuesday 14th March 2023 | week 15 | +| release-1.4 jobs created | CI Manager | Tuesday 14th March 2023 | week 15 | +| v1.4.0-rc.1 released | Release Lead | Tuesday 21st March 2023 | week 16 | +| **v1.4.0 released** | Release Lead | Tuesday 28th March 2023 | week 17 | +| *v1.2.10 & v1.3.4 released* | Release Lead | Tuesday 28th March 2023 | week 17 | +| Organize release retrospective | Release Lead | TBC | week 17 | + +After the `.0` release monthly patch release will be created. + +## Release team + +| **Role** | **Lead Name** (**GitHub / Slack ID**) | **Shadow Name(s) (GitHub / Slack ID)** | +|-------------------------------------------|--------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Release Lead | Yuvaraj Kakaraparthi ([@ykakarap](https://github.com/ykakarap) ✉️ `@Yuvaraj Kakaraparthi`) | Jim Ntosas ([@dntosas](https://github.com/dntosas) ✉️ `@dntosas`)
Carlos Panato ([@cpanato](https://github.com/cpanato) ✉️ `@cpanato`)
Amit Kumar ([@hackeramitkumar](https://github.com/hackeramitkumar) ✉️ `@Amit Kumar`) | +| Communications/Docs/Release Notes Manager | Oscar Utbult ([@oscr](https://github.com/oscr) ✉️ `@oscar`) | Sayantani Saha ([@sayantani11](https://github.com/sayantani11) ✉️ ️`@sayantani`)
Vibhor Chinda ([@VibhorChinda](https://github.com/VibhorChinda) ✉️ ️`@Vibhor Chinda`)
Joe Kratzat ([@joekr](https://github.com/joekr) ✉️ `@Joe Kratzat`) | +| CI Signal/Bug Triage/Automation Manager | Furkat Gofurov ([@furkatgofurov7](https://github.com/furkatgofurov7) ✉️ `@Furkat Gofurov`) | Nawaz Khazielakha ([@nawazkh](https://github.com/nawazkh) ✉️ `@nawazkh`)
Aniruddha Basak ([@aniruddha2000](https://github.com/aniruddha2000/) ✉️ `@aniruddha`)
Alexander Demicev ([@alexander-demicev](https://github.com/alexander-demicev) ✉️ `@Alexander Demicev`) | diff --git a/docs/developer/release-cycle-overview.png b/docs/release/release-cycle-overview.png similarity index 100% rename from docs/developer/release-cycle-overview.png rename to docs/release/release-cycle-overview.png diff --git a/docs/release/release-cycle.md b/docs/release/release-cycle.md new file mode 100644 index 000000000000..90fc02dde9d0 --- /dev/null +++ b/docs/release/release-cycle.md @@ -0,0 +1,52 @@ +# Release Cycle + +The release cycle is the time between when we start working on a release on the `main` branch until the `.0` release (e.g. `v1.3.0`) is released. + +**Note**: For the `v1.3` and `v1.4` releases we assume each release cycle will last approximately 4 months (~ 17 weeks). +The release cycle duration will be revisited after the `v1.4.0` release. + +A release cycle can be split up into the following phases: + +* Week 1-12: Active development + * All changes impacting providers' adoption of Cluster API should be implemented and merged in this period. Exceptions + require special approval as described in the section below. + * Alpha releases will be released based on the main branch only if necessary (to be determined by the release lead) + * Please note that we also publish daily releases based on the main branch. +* Week 13-14: Beta + * Weekly beta releases will be released based on the main branch + * The beta releases are meant as a preview of the upcoming release + * Providers can start adopting the new release based on the beta releases + * All changes that impact providers' adoption of the new release should be announced in the provider updates section + of the office hours meeting notes and approved in the PR or issue by both approvers and key affected providers. +* Week 15-16: RC + * The release branch is created + * Weekly RC releases will be released based on the release branch + * RC releases are as close as possible to the final release but they are still undergoing further testing + * Development of the next release can technically start on the main branch, but some changes might be delayed + to ensure easier cherry-picking of other changes to the release branch. + * There is a feature freeze on the release branch + * Only cherry-picks for documentation, bug fixes, test fixes and test additions are allowed +* Week 17: GA + * `x.y.0` GA release is created based on the release branch +* After that: + * **Note** The following is the responsibility of the release team of the following release cycle. + * `x.y.1+`: Monthly patch releases will be released based on the release branch + * Cherry-picks to the release branch are allowed according to the [backport policy](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#backporting-a-patch) + * Providers create releases using the new CAPI minor release when they are ready + * Development of the next release can now officially start on the main branch + +Some additional notes: + +* Support for new Kubernetes minor versions (for management and workload clusters) is first implemented + on the main branch, then cherry-picked into supported release branches when feasible and eventually + released in the next monthly patch release(s). + * **Note**: We usually don't have to bump Go dependencies to support new Kubernetes minor versions as it's not necessary + to run on a management cluster with the new version or create a workload cluster with the new version. + If it becomes necessary to bump dependencies to a new CR/Kubernetes minor version, the change cannot be cherry-picked + as bumping dependencies to a new minor version is a breaking change. +* New Kubernetes and Controller-Runtime (CR) minor releases are only picked up on the main branch. + +The following diagram visualizes the release cycles with the v1.2, v1.3 and v1.4 releases: + + +![Release Cycle Overview](release-cycle-overview.png) diff --git a/docs/release/release-tasks.md b/docs/release/release-tasks.md new file mode 100644 index 000000000000..d4c259d9cabb --- /dev/null +++ b/docs/release/release-tasks.md @@ -0,0 +1,408 @@ +# Release Tasks + +This document details the responsibilities and tasks for each role in the release team. + +**Notes**: +* The examples in this document are based on the v1.4 release cycle. +* This document focuses on tasks that are done for every release. One-time improvement tasks are out of scope. +* If a task is prefixed with `[Track]` it means it should be ensured that this task is done, but the folks with + the corresponding role are not responsible to do it themselves. + + + +**Table of Contents** + +- [Release Lead](#release-lead) + - [Responsibilities](#responsibilities) + - [Tasks](#tasks) + - [Set a tentative release date for the minor release](#set-a-tentative-release-date-for-the-minor-release) + - [Assemble release team](#assemble-release-team) + - [Finalize release schedule and team](#finalize-release-schedule-and-team) + - [Prepare main branch for development of the new release](#prepare-main-branch-for-development-of-the-new-release) + - [Create a new GitHub milestone for the next release](#create-a-new-github-milestone-for-the-next-release) + - [[Track] Remove previously deprecated code](#track-remove-previously-deprecated-code) + - [[Track] Bump dependencies](#track-bump-dependencies) + - [Create a release branch](#create-a-release-branch) + - [[Continuously] Maintain the GitHub release milestone](#continuously-maintain-the-github-release-milestone) + - [[Repeatedly] Cut a release](#repeatedly-cut-a-release) + - [[Optional] [Track] Bump the Cluster API apiVersion](#optional-track-bump-the-cluster-api-apiversion) + - [[Optional] [Track] Bump the Kubernetes version](#optional-track-bump-the-kubernetes-version) +- [Communications/Docs/Release Notes Manager](#communicationsdocsrelease-notes-manager) + - [Responsibilities](#responsibilities-1) + - [Tasks](#tasks-1) + - [Add docs to collect release notes for users and migration notes for provider implementers](#add-docs-to-collect-release-notes-for-users-and-migration-notes-for-provider-implementers) + - [Update supported versions](#update-supported-versions) + - [Ensure the book for the new release is available](#ensure-the-book-for-the-new-release-is-available) + - [Polish release notes](#polish-release-notes) + - [Change production branch in Netlify to the new release branch](#change-production-branch-in-netlify-to-the-new-release-branch) + - [Update clusterctl links in the quickstart](#update-clusterctl-links-in-the-quickstart) + - [Continuously: Communicate key dates to the community](#continuously-communicate-key-dates-to-the-community) +- [CI Signal/Bug Triage/Automation Manager](#ci-signalbug-triageautomation-manager) + - [Responsibilities](#responsibilities-2) + - [Tasks](#tasks-2) + - [Setup jobs and dashboards for a new release branch](#setup-jobs-and-dashboards-for-a-new-release-branch) + - [[Continuously] Monitor CI signal](#continuously-monitor-ci-signal) + - [[Continuously] Reduce the amount of flaky tests](#continuously-reduce-the-amount-of-flaky-tests) + - [[Continuously] Bug triage](#continuously-bug-triage) + + + +## Release Lead + +### Responsibilities + +* Coordination: + * Take ultimate accountability for all release tasks to be completed on time + * Coordinate release activities + * Create and maintain the GitHub release milestone + * Track tasks needed to add support for new Kubernetes versions in upcoming releases + * Ensure a retrospective happens +* Staffing: + * Assemble the release team for the current release cycle + * Ensure a release lead for the next release cycle is selected and trained + * Set a tentative release date for the next release cycle +* Cutting releases: + * Release patch releases for supported previous releases at least monthly or more often if needed + * Create beta, RC and GA releases for the minor release of the current release cycle +* Release lead should keep an eye on what is going on in the project to be able to react if necessary + +### Tasks + +#### Set a tentative release date for the minor release + +1. Set a tentative release date for the release and document it by creating a `release-1.4.md`. + +#### Assemble release team + +There is currently no formalized process to assemble the release team. +As of now we ask for volunteers in Slack and office hours. + +#### Finalize release schedule and team + +1. Finalize release schedule and team in `release-1.4.md`. +2. Update Slack user group and GitHub team accordingly. +
Prior art: https://github.com/kubernetes-sigs/cluster-api/issues/7476 + +#### Prepare main branch for development of the new release + +The goal of this issue is to bump the versions on the main branch so that the upcoming release version +is used for e.g. local development and e2e tests. We also modify tests so that they are testing the previous release. + +This comes down to changing occurrences of the old version to the new version, e.g. `v1.3` to `v1.4`: +1. Add new release to top-level `metadata.yaml` and `test/e2e/data/shared/v1beta1/metadata.yaml`. +2. Update providers in docker.yaml. Roughly: + 1. Create a new entry for each provider for `v1.3.0`. + 2. Rename `v1.3.99` to `v1.4.99`. +3. Modify the test specs in `test/e2e/clusterctl_upgrade_test.go`. +4. Update `create-local-repository.py` and `tools/tilt-prepare/main.go`: `v1.3.99` => `v1.4.99`. +5. Make sure all tests are green (also run `pull-cluster-api-e2e-full-main` and `pull-cluster-api-e2e-workload-upgrade-1-23-latest-main`). + +Prior art: https://github.com/kubernetes-sigs/cluster-api/pull/6834/files + +#### Create a new GitHub milestone for the next release + +The goal of this task is to create a new GitHub milestone for the next release, so that we can already move tasks +out of the current milestone if necessary. + +1. Create the milestone for the new release via GitHub UI. + +#### [Track] Remove previously deprecated code + +The goal of this task is to remove all previously deprecated code that can be now removed. + +1. Check for deprecated code and remove it. + * We can't just remove all code flagged with `Deprecated`. In some cases like e.g. in API packages + we have to keep the old code. + +Prior art: [Remove code deprecated in v1.2](https://github.com/kubernetes-sigs/cluster-api/pull/6779) + +#### [Track] Bump dependencies + +The goal of this task is to ensure that we have relatively up-to-date dependencies at the time of the release. +This reduces the risk that CVEs are found in outdated dependencies after our release. + +We should take a look at the following dependencies: +* Go dependencies in `go.mod` files. +* Tools used in our Makefile (e.g. kustomize). + +#### Create a release branch + +The goal of this task is to ensure we have a release branch and the milestone applier applies milestones accordingly. +From this point forward changes which should land in the release have to be cherry-picked into the release branch. + +1. Create the release branch locally based on the latest commit on main and push it: + ```bash + # Create the release branch + git checkout -b release-1.4 + + # Push the release branch + # Note: `upstream` must be the remote pointing to `github.com/kubernetes-sigs/cluster-api`. + git push -u upstream release-1.4 + ``` +2. Update the [milestone applier config](https://github.com/kubernetes/test-infra/blob/0b17ef5ffd6c7aa7d8ca1372d837acfb85f7bec6/config/prow/plugins.yaml#L371) accordingly (e.g. `release-1.4: v1.4` and `main: v1.5`) +
Prior art: [cluster-api: update milestone applier config for v1.3](https://github.com/kubernetes/test-infra/pull/26631) + +#### [Continuously] Maintain the GitHub release milestone + +The goal of this task is to keep an overview over the current release milestone and the implementation +progress of issues assigned to the milestone. + +This can be done by: +1. Regularly checking in with folks implementing an issue in the milestone. +2. If nobody is working on an issue in the milestone, drop it from the milestone. +3. Ensuring we have a plan to get `release-blocking` issues implemented in time. + +#### [Repeatedly] Cut a release + +1. Ensure CI is stable before cutting the release (e.g. by checking with the CI manager) +2. Create and push the release tags to the GitHub repository: + ```bash + # Export the tag of the release to be cut, e.g.: + export RELEASE_TAG=v1.0.1 + + # Create tags locally + # Warning: The test tag MUST NOT be an annotated tag. + git tag -s -a ${RELEASE_TAG} -m ${RELEASE_TAG} + git tag test/${RELEASE_TAG} + + # Push tags + # Note: `upstream` must be the remote pointing to `github.com/kubernetes-sigs/cluster-api`. + git push upstream ${RELEASE_TAG} + git push upstream test/${RELEASE_TAG} + ``` + **Note**: This will automatically trigger a [GitHub Action](https://github.com/kubernetes-sigs/cluster-api/actions/workflows/release.yml) to create a draft release and a [ProwJob](https://prow.k8s.io/?repo=kubernetes-sigs%2Fcluster-api&job=post-cluster-api-push-images) to publish images to the staging repository. +3. Promote images from the staging repository to the production registry (`registry.k8s.io/cluster-api`): + 1. Wait until images for the tag have been built and pushed to the [staging repository](https://console.cloud.google.com/gcr/images/k8s-staging-cluster-api) by the [post push images job](https://prow.k8s.io/?repo=kubernetes-sigs%2Fcluster-api&job=post-cluster-api-push-images). + 2. If you don't have a GitHub token, create one by going to your GitHub settings, in [Personal access tokens](https://github.com/settings/tokens). Make sure you give the token the `repo` scope. + 3. Create a PR to promote the images to the production registry: + ```bash + export GITHUB_TOKEN= + make promote-images + ``` + **Notes**: + * `kpromo` uses `git@github.com:...` as remote to push the branch for the PR. If you don't have `ssh` set up you can configure + git to use `https` instead via `git config --global url."https://github.com/".insteadOf git@github.com:`. + * This will automatically create a PR in [k8s.io](https://github.com/kubernetes/k8s.io) and assign the CAPI maintainers. + 4. Merge the PR (/lgtm + /hold cancel) and verify the images are available in the production registry: + ```bash + docker pull registry.k8s.io/cluster-api/clusterctl:${RELEASE_TAG} + docker pull registry.k8s.io/cluster-api/cluster-api-controller:${RELEASE_TAG} + docker pull registry.k8s.io/cluster-api/kubeadm-bootstrap-controller:${RELEASE_TAG} + docker pull registry.k8s.io/cluster-api/kubeadm-control-plane-controller:${RELEASE_TAG} + ``` +4. Publish the release in GitHub: + 1. Get the final release notes from the docs team and add them to the GitHub release. + 2. Publish the release (ensure to flag the release as pre-release if necessary). +5. Publish `clusterctl` to Homebrew by bumping the version in [clusterctl.rb](https://github.com/Homebrew/homebrew-core/blob/master/Formula/clusterctl.rb). +
**Notes**: + * This is only done for new latest stable releases, not for beta / RC releases and not for previous release branches. + * For an example please see: [PR: clusterctl 1.1.5](https://github.com/Homebrew/homebrew-core/pull/105075/files). + * Homebrew has [conventions for commit messages](https://docs.brew.sh/Formula-Cookbook#commit) usually + the commit message for us should look like: `clusterctl 1.1.5`. +6. Set EOL date for previous release (prior art: https://github.com/kubernetes-sigs/cluster-api/issues/7146). + +Additional information: +* [Versioning documentation](./../../CONTRIBUTING.md#versioning) for more information. +* Cutting a release as of today requires permissions to: + * Create a release tag on the GitHub repository. + * Create/update/publish GitHub releases. + +#### [Optional] [Track] Bump the Cluster API apiVersion + +**Note** This should only be done when we have to bump the apiVersion of our APIs. + +1. Add new version of the types: + 1. Create new api packages by copying existing packages. + 2. Make sure webhooks only exist in the latest apiVersion (same for other subpackages like `index`). + 3. Add conversion and conversion tests. + 4. Adjust generate targets in the Makefile. + 5. Consider dropping fields deprecated in the previous apiVersion. +2. Update import aliases in `.golangci.yml`. +3. Switch other code over to the new version (imports across the code base, e.g. controllers). + 1. Add all versions to the schema in the `main.go` files. +4. Add types to the `PROJECT` files of the respective provider. +5. Add test data for the new version in `test/e2e/data/{infrastructure-docker,shared}` (also update top-level `.gitignore`). +6. Update `docker.yaml`, make sure all tests are successful in CI. + +#### [Optional] [Track] Bump the Kubernetes version + +TODO(sbueringer): Follow-up PR (this will probably just be create an issue based on another issue template) + +## Communications/Docs/Release Notes Manager + +### Responsibilities + +* Communication: + * Communicate key dates to the community +* Documentation: + * Improve release process documentation + * Ensure the book and provider upgrade documentation are up-to-date + * Maintain and improve user facing documentation about releases, release policy and release calendar +* Release Notes: + * Polish release notes + +### Tasks + +#### Add docs to collect release notes for users and migration notes for provider implementers + +The goal of this task is to initially create the docs so that we can continuously add notes going forward. +The release notes doc will be used to collect release notes during the release cycle and will be eventually +used to write the final release notes. The provider migration doc is part of the book and contains instructions +for provider authors on how to adopt to the new Cluster API version. + +1. Add a new migration doc for provider implementers. +
Prior art: [Add v1.2 -> v1.3 migration doc](https://github.com/kubernetes-sigs/cluster-api/pull/6698) +2. Add a doc to collect initial release notes for users. + +#### Update supported versions + +1. Update supported versions in versions.md. +
Prior art: [Update supported versions for v1.3](https://github.com/kubernetes-sigs/cluster-api/pull/6850) + +#### Ensure the book for the new release is available + +The goal of this task to make the book for the current release available under e.g. `https://release-1-4.cluster-api.sigs.k8s.io`. + +1. Add a DNS entry for the book of the new release (should be available under e.g. `https://release-1-4.cluster-api.sigs.k8s.io`). +
Prior art: [Add DNS for CAPI release-1.2 release branch](https://github.com/kubernetes/k8s.io/pull/3872) +2. Open `https://release-1-4.cluster-api.sigs.k8s.io/` and verify that the certificates are valid + If they are not, talk to someone with access to Netlify, they have to click the `renew certificate` button in the Netlify UI. +3. Update references in introduction.md only on the main branch (drop unsupported versions, add the new release version). +
Prior art: [Add release 1.2 book link](https://github.com/kubernetes-sigs/cluster-api/pull/6697) + +#### Polish release notes + +1. Checkout the latest commit on the release branch, e.g. `release-1.4`. +2. Generate release notes with: + ```bash + # PREVIOUS_TAG should be the last patch release of the previous minor release. + PREVIOUS_TAG=v1.3.x + go run ./hack/tools/release/notes.go --from=${PREVIOUS_TAG} > tmp.md + ``` +3. Finalize the release notes: + 1. Copy & paste the release notes into a hackmd (makes collaboration very easy). + 2. Pay close attention to the `## :question: Sort these by hand` section, as it contains items that need to be manually sorted. + 3. Ensure consistent formatting of entries (e.g. prefix (see [v1.2.0](https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.2.0) release notes)). + 4. Merge dependency bump PR entries for the same dependency into a single entry. + 5. Move minor changes into a single line at the end of each section. + 6. Sort entries within a section alphabetically. + 7. Write highlights section based on the initial release notes doc. + 8. Add Kubernetes version support section. +4. Iterate until the GA release by generating incremental release notes and modifying the release notes in hackmd accordingly: + ```bash + # PREVIOUS_TAG should be the tag from which the previous release notes have been generated, e.g.: + PREVIOUS_TAG=v1.4.0-rc.0 + go run ./hack/tools/release/notes.go --from=${PREVIOUS_TAG} > tmp.md + ``` + +#### Change production branch in Netlify to the new release branch + +The goal of this task to make the book for the current release available under `https://cluster-api.sigs.k8s.io`. + +Someone with access to Netlify should: +1. Change production branch in Netlify the current release branch (e.g. `release-1.4`) to make the book available under `https://cluster-api.sigs.k8s.io`. +2. Re-deploy via the Netlify UI. + +#### Update clusterctl links in the quickstart + +The goal of this task is to ensure the quickstart has links to the latest `clusterctl` binaries. + +1. Update clusterctl links in the quickstart (on main and cherry-pick onto release-1.4). +
Prior art: [Update clusterctl version to v1.2.x in quick start](https://github.com/kubernetes-sigs/cluster-api/pull/6716) + +**Note**: The PR for this should be merged after the minor release has been published. + +#### Continuously: Communicate key dates to the community + +The goal of this task is to ensure all stakeholders are informed about the current release cycle. + +Information can be distributed via: (TBD) +* `sig-cluster-lifecycle` mailing list +* Slack +* Office hours +* ClusterAPI book +* ... + +Relevant information includes: (TBD) +* Beta, RC, GA release +* Start of code freeze +* Implementation progress +* ... + +Stakeholders are: (TBD) +* End users of ClusterAPI +* Contributors to core ClusterAPI +* Provider implementers +* ... + +## CI Signal/Bug Triage/Automation Manager + +### Responsibilities + +* Signal: + * Responsibility for the quality of the release + * Continuously monitor CI signal, so a release can be cut at any time + * Add CI signal for new release branches +* Bug Triage: + * Make sure blocking issues and bugs are triaged and dealt with in a timely fashion +* Automation + * Maintain and improve release automation, tooling & related developer docs + +### Tasks + +#### Setup jobs and dashboards for a new release branch + +The goal of this task is to have test coverage for the new release branch and results in testgrid. + +1. Create new jobs based on the jobs running against our `main` branch: + 1. Copy `config/jobs/kubernetes-sigs/cluster-api/cluster-api-periodics-main.yaml` to `config/jobs/kubernetes-sigs/cluster-api/cluster-api-periodics-release-1-4.yaml`. + 2. Copy `test-infra/config/jobs/kubernetes-sigs/cluster-api/cluster-api-periodics-main-upgrades.yaml` to `test-infra/config/jobs/kubernetes-sigs/cluster-api/cluster-api-periodics-release-1-4-upgrades.yaml`. + 3. Copy `test-infra/config/jobs/kubernetes-sigs/cluster-api/cluster-api-presubmits-main.yaml` to `test-infra/config/jobs/kubernetes-sigs/cluster-api/cluster-api-presubmits-release-1-4.yaml`. + 4. Modify the following: + 1. Rename the jobs, e.g.: `periodic-cluster-api-test-main` => `periodic-cluster-api-test-release-1-4`. + 2. Change `annotations.testgrid-dashboards` to `sig-cluster-lifecycle-cluster-api-1.4`. + 3. Change `annotations.testgrid-tab-name`, e.g. `capi-test-main` => `capi-test-release-1-4`. + 4. For periodics additionally: + * Change `extra_refs[].base_ref` to `release-1.4` (for repo: `cluster-api`). + * Change interval (let's use the same as for `1.3`). + 5. For presubmits additionally: Adjust branches: `^main$` => `^release-1.4$`. +2. Create a new dashboard for the new branch in: `test-infra/config/testgrids/kubernetes/sig-cluster-lifecycle/config.yaml` (`dashboard_groups` and `dashboards`). +3. Verify the jobs and dashboards a day later by taking a look at: `https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api-1.4` + +Prior art: [Add jobs for CAPI release 1.2](https://github.com/kubernetes/test-infra/pull/26621) + +#### [Continuously] Monitor CI signal + +The goal of this task is to keep our tests running in CI stable. + +**Note**: To be very clear, this is not meant to be an on-call role for Cluster API tests. + +1. Add yourself to the [Cluster API alert mailing list](https://github.com/kubernetes/k8s.io/blob/151899b2de933e58a4dfd1bfc2c133ce5a8bbe22/groups/sig-cluster-lifecycle/groups.yaml#L20-L35) + **Note**: An alternative to the alert mailing list is manually monitoring the [testgrid dashboards](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api) + (also dashboards of previous releases). Using the alert mailing list has proven to be a lot less effort though. +2. Triage CI failures reported by mail alerts or found by monitoring the testgrid dashboards: + 1. Create an issue in the Cluster API repository to surface the CI failure. + 2. Identify if the issue is a known issue, new issue or a regression. + 3. Mark the issue as `release-blocking` if applicable. + +#### [Continuously] Reduce the amount of flaky tests + +The Cluster API tests are pretty stable, but there are still some flaky tests from time to time. + +To reduce the amount of flakes please periodically: +1. Take a look at recent CI failures via `k8s-triage`: + * [periodic-cluster-api-e2e-main](https://storage.googleapis.com/k8s-triage/index.html?pr=1&job=periodic-cluster-api-e2e-main) + * [periodic-cluster-api-e2e-mink8s-main](https://storage.googleapis.com/k8s-triage/index.html?pr=1&job=periodic-cluster-api-e2e-mink8s-main) + * [periodic-cluster-api-test-main](https://storage.googleapis.com/k8s-triage/index.html?pr=1&job=periodic-cluster-api-test-main) + * [periodic-cluster-api-test-mink8s-main](https://storage.googleapis.com/k8s-triage/index.html?pr=1&job=periodic-cluster-api-test-mink8s-main) +3. Open issues for occurring flakes and ideally fix them or find someone who can. + **Note**: Given resource limitations in the Prow cluster it might not be possible to fix all flakes. + Let's just try to pragmatically keep the amount of flakes pretty low. + +#### [Continuously] Bug triage + +The goal of bug triage is to triage incoming issues and if necessary flag them with `release-blocking` +and add them to the milestone of the current release. + +We probably have to figure out some details about the overlap between the bug triage task here, release leads +and Cluster API maintainers. diff --git a/docs/developer/release-team.md b/docs/release/release-team.md similarity index 94% rename from docs/developer/release-team.md rename to docs/release/release-team.md index ea4148e3829b..d7743e978e6a 100644 --- a/docs/developer/release-team.md +++ b/docs/release/release-team.md @@ -21,7 +21,7 @@ This document introduces the concept of a release team with the following goals Note that this document is intended to be a starting point for the release team. It is not a complete release process document. -More details on the CAPI release process can be found in [this past issue tracking release tasks](https://github.com/kubernetes-sigs/cluster-api/issues/6615) and the current [release documentation](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/developer/releasing.md). +More details on the CAPI release process can be found in the [release cycle](./release-cycle.md) and [release task](./release-tasks.md) documentation. ## Duration of Term @@ -51,6 +51,8 @@ As noted above, making changes to the CAPI release cadence is out of scope for - **CI Signal/Bug Triage/Automation Manager**: Assumes the responsibility of the quality gate for the release and makes sure blocking issues and bugs are triaged and dealt with in a timely fashion. Helps improve release automation and tools. - **Shadow**: Any Release Team member may select one or more mentees to shadow the release process in order to help fulfill future Release Team staffing requirements and continue to grow the CAPI community in general. +*Note*: This is also documented in [Release tasks](./release-tasks.md) together with a mapping to specific tasks. + ## Team Selection To start, the release team will be assembled by the release team lead based on volunteers. A call for volunteers can be made through the usual communication channels (office hours, Slack, mailing list, etc.). In the future, we may consider introducing an application process similar to the Kubernetes release team application process. @@ -77,4 +79,4 @@ Volunteering to be part of a CAPI release team is a great way to contribute to t - Get more familiar with the CAPI release process - Create lasting relationships with other members of the community -- Contribute to the CAPI project health \ No newline at end of file +- Contribute to the CAPI project health diff --git a/hack/verify-doctoc.sh b/hack/verify-doctoc.sh index 0c510fb9d553..02f276066e28 100755 --- a/hack/verify-doctoc.sh +++ b/hack/verify-doctoc.sh @@ -27,9 +27,9 @@ command -v doctoc || echo "doctoc is not available on your system, skipping veri doctoc_files="README.md \ CONTRIBUTING.md \ cmd/clusterctl/README.md \ + docs/release/release-tasks.md \ docs/scope-and-objectives.md \ docs/staging-use-cases.md \ - docs/developer/releasing.md \ docs/proposals/20181121-machine-api.md \ docs/proposals/20190610-machine-states-preboot-bootstrapping.md \ docs/proposals/YYYYMMDD-template.md"