Adding release cut onboarding handbook #2731
Conversation
k8s-ci-robot added kind/documentation k8s-ci-robot added sig/release 
| /hold until this gets more eyes on it and some consensus |
k8s-ci-robot added the do-not-merge/hold 
| Thanks for the update to the docs Matteo, updates to docs are always needed and welcome! Note, however, that this is duplicating the image promotion docs and the branch manager handbook (check the Releases Management section). So I think it's better if we update the kpromo docs and the handbook based on your notes. |
Thanks for the review! @puerco Note: As I am currently onboarding I surely lack the context and historical reasons behind the choice of having those as fragmented docs. I found (and still find) those docs to be a tiny bit difficult to navigate as a new contributor and more focused on giving a general overview on the process rather than a straightforward step by step guide to actually perform a release cut. The option I find viable are the following: 1. Integrating and substitutingIntegrate the existing content in this new handbook so that it can become a more complete guide focused just on release cuts (including a step by step guide) - and linking it back in the branch manager handbook as follows: I have no opinion on temporarily duplicating some of the content and initially keep it in both places, but in the long term I think it would be better to have smaller focused and step by step guides and kind of "breaking down" the current branch manager handbook in smaller, more digestible chunks. Another example would be having a "post rc.0 tasks" handbook in a separate file - linked accordingly everywhere where it's needed. 2. Just linkingLinking this new bite sized guide as it is in the references section of the branch manager handbook and remove legacy links as follows: Let me know what you think! |
Update k8s-release-cut.md
Update cut-release.md
Update k8s-release-cut.md
Update branch-manager.md
Update branch-manager.md
Update branch-manager.md
| /unhold Work is mostly done for - can this get some eyes on? @kubernetes/release-managers |
k8s-ci-robot removed the do-not-merge/hold | /assign |
| /assign |
| /assign |
k8s-ci-robot added the lgtm 
| [APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mbianchidev, Verolop The full list of commands accepted by this bot can be found here. The pull request process is described here Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot added the approved 
| | ||
| ## Release Steps | ||
| | ||
| - [ ] Ensure a green signal has been given by Release Signal **on the day of the cut** |
There was a problem hiding this comment.
I would clarify that this is only for the prereleases, we don't have a green release signal for other releases (in fact, that's covered by Screenshot unhealthy release branch testgrid boards for other releases)
There was a problem hiding this comment.
Agreed, we need to fix this!
| - [ ] Update [`schedule.yaml` file](https://github.com/kubernetes/website/blob/main/data/releases/schedule.yaml) with the latest release using [`schedule-builder`](https://github.com/kubernetes/release/tree/master/cmd/schedule-builder) (_patch releases only_) <!-- Paste Pull Request URL here --> | ||
| - [ ] Collect metrics and add them to the `Release steps` table below through `krel history --branch release-1.xx --date-from yyyy-mm-dd` (current date) | ||
| <!-- ONLY FOR RC.0 RELEASES - [ ] Finish post-release branch creation tasks --> | ||
| <!-- ONLY FOR STABLE RELEASES - [ ] Code Thaw PR merged --> |
There was a problem hiding this comment.
Should be only for .0 release (stable releases are all >= .0 releases technically)
There was a problem hiding this comment.
Agreed, we need to fix this!
| @@ -0,0 +1,520 @@ | |||
| # Cutting a Kubernetes release | |||
| | |||
| A step by step guide for cutting Kubernetes patch releases. At a high-level: | |||
There was a problem hiding this comment.
- This is in fact for cutting any release, not only patch releases
- We should somewhere mentions what tasks are safe to be run in parallel
There was a problem hiding this comment.
Agreed, we need to implement these imho!
| ### Green Release Signal | ||
| | ||
| On the same day of the release, a green signal must've been given in the #release-management Slack channel. If in doubt, double check with the current Release Signal Team Lead. | ||
| You can find the complete list of release signal team members at this link (substitute `1.xx` with the current release version): | ||
| | ||
| `https://github.com/kubernetes/sig-release/blob/master/releases/release-1.xx/release-team.md` |
There was a problem hiding this comment.
It's important to emphasise that this is only for prereleases. The Release Signal Team doesn't have anything to do with patch releases.
There was a problem hiding this comment.
Agreed, we need to fix it
| | ||
| ### Access to GCP | ||
| | ||
| You must be a member of [k8s-infra-release-editors](https://github.com/kubernetes/k8s.io/blob/main/groups/sig-release/groups.yaml) on GitHub. |
There was a problem hiding this comment.
k8s-infra-release-editors is a Google group, so maybe we should rephrase this as:
You must a member of the
k8s-infra-release-editors@kubernetes.ioGoogle group to be able to cut releases. You can add yourself to the group by updating the appropriategroups.yamlfile in thekubernetes/k8s.iorepository.
There was a problem hiding this comment.
Agreed, we need to fix it (I was probably thinking about work when writing this one, lol)
There was a problem hiding this comment.
We should consider removing the release steps from this guide now that we have the other document.
There was a problem hiding this comment.
/other-doc-change
I will gladly do it, see this comment that summarizes how I feel about duplicating content.
I can take this on as a task, to clean up stuff from the main handbook and instead link to this one.
| | ||
| Behind the scenes `krel` is doing a git branch create and git push. The branch is created in the staging phase and is pushed to the repository in the release phase. | ||
| - Fork the [test-infra repository](https://github.com/kubernetes/test-infra) | ||
| - Clone their fork of `kubernetes/test-infra`: |
There was a problem hiding this comment.
Yep, needs a quick fix
| - (optional) [Install Bazel](https://docs.bazel.build/versions/master/install.html) or run Bazel inside a container | ||
| - Running Bazel in a container is recommended over installing Bazel locally, as Bazel has many dependencies |
There was a problem hiding this comment.
Why do we exactly need Bazel for?
There was a problem hiding this comment.
/discuss
This was a set of prerequirements that I inherited from @jimangel - gut feeling is maybe for the rc.0 cut? Or maybe the scheduler updates? I didn't really use it or installed it tbh. I lack context to answer.
There was a problem hiding this comment.
Yes, I also don't have Bazel installed, I thought it's long time gone. We'd need to verify this.
| | ||
| #### After the release creation | ||
| At the same time Prow’s [`branchprotector`](https://git.k8s.io/test-infra/prow/cmd/branchprotector/README.md) runs every hour at 54 minutes past the hour and automatically adds [branch protection](https://help.github.com/articles/about-protected-branches/) to any new branch in the `kubernetes/kubernetes` repo, including the newly created one. | ||
| No need to manually create the branch protection rule. |
There was a problem hiding this comment.
I would add that you should ensure that the branch gets protected. We had some cases where that didn't happen.
There was a problem hiding this comment.
Ah, then yes great addition.
| | ||
| ### Update test-infra configurations | ||
| > [!NOTE] | ||
| This means that the staging step will take about twice as long, as it will stage both versions `v1.18.0-rc.0` and `v1.19.0-alpha.0`. |
There was a problem hiding this comment.
One thing we should mention in the new handbook is that in this case, you should promote release by release. In fact, you must always promote only one release in a single PR.
There was a problem hiding this comment.
I think I mentioned it somewhere but here I forgot to do it, let's fix it
6 participants
This PR is the result of merging my onboarding notes and a HackMD provided during my first release cut.
What type of PR is this:
/kind documentation
/priority important-longterm
What this PR does / why we need it:
This is part of a bigger plan to document release engineering processes meanwhile I get onboarded in the team.
The doc is meant to be scoped to just cover a release cut and provide a step by step guide to perform it.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
CC: @jimangel