You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/cut-release.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,8 +87,8 @@ Help? Ring @release-managers on slack!
87
87
-[ ] Notify #release-management on Slack: <!-- Paste link to slack -->
88
88
-[ ] 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 -->
89
89
-[ ] 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)
90
-
<!-- ONLY FOR RC.0 RELEASES - [ ] Finish post-release branch creation tasks -->
91
-
<!-- ONLY FOR STABLE RELEASES - [ ] Code Thaw PR merged -->
90
+
<!-- ONLY FOR RC.0 RELEASES - [ ] Post-release branch creation tasks -->
91
+
<!-- ONLY FOR .0 RELEASE - [ ] Code Thaw PR merged and OBS project created for the new minor release-->
about: Tasks to perform after the rc.0 is cut and the upcoming release branch is created
4
+
title: Post Release Branch Creation Tasks for v1.x.y-rc.0
5
+
labels: sig/release, area/release-eng
6
+
---
7
+
8
+
## As a follow up on: <!-- #<issue> typically the rc.0 cut issue (currently the branch is created by krel during that cut process) -->
9
+
10
+
## Tasks
11
+
12
+
<!--
13
+
14
+
Follow the docs here: https://github.com/kubernetes/sig-release/blob/master/release-engineering/handbooks/post-release-branch-creation.md
15
+
16
+
Help? Ring @release-managers on slack!
17
+
18
+
-->
19
+
20
+
-[ ] Create a thread in #release-management: <!-- Paste link to Slack thread -->
21
+
-[ ] (optional) Remove jobs for EOL versions, **only** if agreed upon with Release Managers
22
+
<!--
23
+
Branch Managers might not have a context on if it is "safe" to remove the EOL jobs. We try to be firm with the deadlines and stop cutting patches as soon as we reach the EOL date, but e.g. there might be a new patch needed because of some important security fix, in which case only Release Managers will know about that.
24
+
25
+
There might be a significant time/delay between the release reaching EOL and the new branch being created, leaving those jobs hanging for a while, which has an impact on the project infra costs.
26
+
27
+
The trigger for removing such jobs should be solely the EOL date but we shouldn't connect getting rid of EOL jobs and the new branch creation. Even if has been like that before, it shouldn't be longterm.
-[ ] Update [`kubekins-e2e-v2/variants.yaml`](https://github.com/kubernetes/test-infra/blob/master/images/kubekins-e2e-v2/variants.yaml) with the new version config
31
+
-[ ] Rotate configuration of release branch jobs in kubernetes/test-infra in particular `releng/test_config.yaml` for the upcoming release
32
+
-[ ] Run test generation script, configure the new release dashboards and send a PR with both tests and dashboards config
33
+
-[ ] Add a new variant for the `kube-cross` image (`kubernetes/release` repository) and ensure the image is built and pushed properly
34
+
-[ ] Add new variants for `k8s-cloud-builder` and `k8s-ci-builder` images (`kubernetes/release` repository) and ensure images are built and pushed properly
35
+
-[ ] Update references in `kubernetes/kubernetes` with the new kube-cross image (only after all images are pushed/promoted)
36
+
-[ ] Update publishing-bot rules to include the new release branch
37
+
-[ ] Ensure that a new [performance tests](https://github.com/kubernetes/perf-tests/) branch is created by SIG Scalability maintainers
38
+
-[ ] Inform stakeholders about the post branch creation tasks being completed
39
+
-[ ] Monitor the new release dashboard with the Release Signal Lead for at least 48 hours - mainly for missing or misconfigured jobs
40
+
41
+
## Action Items
42
+
43
+
<!--
44
+
During the post rc tasks, you may find a few things that require updates
45
+
(process changes, documentation updates, fixes to release tooling).
46
+
47
+
Please list them here.
48
+
49
+
It will be your responsibility to open issues/PRs to resolve these
50
+
issues/improvements. Keep this issue open until these action items
51
+
are complete.
52
+
53
+
- [ ] Item 1
54
+
- [ ] Item 2
55
+
- [ ] Item 3
56
+
-->
57
+
58
+
## Open Questions
59
+
60
+
<!--
61
+
During the post rc tasks, you may have a few questions that you can't
62
+
answer yourself or may require group discussion.
63
+
64
+
Please list them here.
65
+
66
+
Follow up with Branch Managers/Patch Release Team/Release Engineering
67
+
subproject owners to get these questions answered.
68
+
69
+
- [ ] Item 1
70
+
- [ ] Item 2
71
+
- [ ] Item 3
72
+
-->
73
+
74
+
/milestone <!-- v1.x e.g. v1.14 -->
75
+
/assign <!-- @ the Release or Branch Manager responsible for this release -->
-[\[Patch only\] Update schedule on k/website](#patch-only-update-schedule-on-kwebsite)
34
+
-[Cleanup](#cleanup)
35
+
3
36
A step by step guide for cutting Kubernetes patch releases. At a high-level:
4
37
5
38
- Maintain GitHub release cut issue
@@ -15,13 +48,17 @@ A step by step guide for cutting Kubernetes patch releases. At a high-level:
15
48
16
49
## Prerequisites
17
50
18
-
### Green Release Signal
51
+
### Green Release Signal (pre-releases only)
19
52
20
53
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.
21
54
You can find the complete list of release signal team members at this link (substitute `1.xx` with the current release version):
Ensure that there are no patch releases in progress, coordinating with @release-managers.
60
+
These are typically scheduled on different days of the week, so there is usually no need to plan around them, but since they can sometimes overlap with other release activities, it's good to double-check.
61
+
25
62
### Access to GCP
26
63
27
64
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.
@@ -117,10 +154,18 @@ krel version
117
154
118
155
#### Download or update the latest `kpromo` tool
119
156
120
-
Run the following command ([source](https://github.com/kubernetes-sigs/promo-tools/blob/main/docs/promotion-pull-requests.md#preparing-environment)):
157
+
Run the following command ([source](https://github.com/kubernetes-sigs/promo-tools/blob/main/docs/promotion-pull-requests.md#preparing-environment)) to get the latest release of `kpromo`:
158
+
159
+
```
160
+
go install sigs.k8s.io/promo-tools/v4/cmd/kpromo@main
161
+
```
162
+
163
+
or to build the latest version directly from a target branch:
121
164
122
165
```
123
-
go install sigs.k8s.io/promo-tools/v4/cmd/kpromo@latest
@@ -248,6 +293,9 @@ If the issue is open you must stop the release process and inform #release-manag
248
293
249
294
## 5. Mock stage and Mock release
250
295
296
+
> [!WARNING]
297
+
Before cutting `alpha.1` ideally some days before, ensure that @release-managers have performed the propedeutic tasks for the alpha cut (e.g. setting up the new OBS project)
298
+
251
299
Mock stages and mock releases are non-destructive and can be reran upon failure. To begin the mock stage, run the following `krel stage` command (replace the stage with the appropriate "type").
252
300
253
301
Run the following command from within the release repo directory.
@@ -477,12 +525,38 @@ krel history --branch release-1.33 --date-from 2025-04-23
477
525
478
526
## 10. Post release tasks
479
527
480
-
### [RC.0 only] Post rc.0 release tasks
528
+
### [RC.0 only] Considerations and post branch creation release tasks
529
+
530
+
Remember that before launching the `nomock release` command for an rc.0, you need to ensure that the image promo job for the next alpha.0 has been completed successfully.
481
531
482
-
See [here](post-rc0-release-tasks.md) for the complete list of post rc.0 release tasks.
532
+
#### Next Release Branch Creation
533
+
534
+
> [!IMPORTANT]
535
+
> The new release branch is created in the `nomock` staging phase and pushed to the repository during the `nomock` release phase of an rc.0 cut.
536
+
537
+
During a `rc.0` release our release tooling creates a new release branch named `release-X.Y`, where `X.Y.0` is the version of the upcoming release.
538
+
Additionally, the `rc.0` release automatically triggers an `alpha.0` build for the subsequent release (e.g. for `v1.34.0-rc.0`, `v1.35.0-alpha.0` is created automatically).
539
+
540
+
Behind the scenes `krel` is executing a `git branch create` command and `git push`.
541
+
542
+
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.
543
+
No need to manually create the branch protection rule.
544
+
545
+
However, it is important to ensure that the branch is protected. We had cases where the branch was not protected and this was noticed very late.
546
+
547
+
> [!NOTE]
548
+
This means that the staging step will take about twice as long, as it will stage both versions `vX.Y.0-rc.0` and `vX.{Y+1}.0-alpha.0`.
549
+
The release step will also be extended, but not substantially longer in time.
550
+
551
+
#### Post branch creation release tasks
552
+
553
+
See [here](post-rc0-release-tasks.md) for the complete list of post branch creation release tasks.
483
554
484
555
Such list resides in a different document to mainain this one in a bite-sized SRE style format.
485
556
557
+
> [!WARNING]
558
+
You will not be able to cut an rc.1 or any other cut against the new branch until the post branch creation tasks (post rc.0) are complete.
559
+
486
560
### [Stable only] Code Thaw
487
561
488
562
Code thaw means you need to lift the code freeze, [here](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/branch-manager.md#code-thaw)
0 commit comments