External-Mirrors/kubespray
2
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kubespray.git synced 2026-10-29 22:03:22 -02:30
Code Issues Packages Projects Releases Wiki Activity

docs: require daily CI before tagging a release (#13207)

Browse Source 
* docs: require full CI before tagging a release

Signed-off-by: Kay Yan <kay.yan@daocloud.io>

* docs: use daily CI as release gate

Signed-off-by: Kay Yan <kay.yan@daocloud.io>

* docs: clarify daily CI release check

Signed-off-by: Kay Yan <kay.yan@daocloud.io>

---------

Signed-off-by: Kay Yan <kay.yan@daocloud.io>
This commit is contained in:
Kay Yan
2026-09-26 10:14:32 +00:00
committed by GitHub
parent e62c778293
commit 687e1dcbc2
1 changed files with 1 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
RELEASE.md
+1
View File
@@ -7,6 +7,7 @@ The Kubespray Project is released on an as-needed basis. The process is as follo
1. (Only for major releases) Keep Kubernetes binary checksums and per-minor component mappings for the default Kubernetes minor and the two previous minors (a support floor of `n-2`). The oldest `kubelet_checksums` entry determines `kube_version_min_required`.
1. (Only for major releases) Remove hashes for [EOL versions](https://github.com/kubernetes/website/blob/main/content/en/releases/patch-releases.md) of kubernetes from `*_checksums` variables.
1. Create the release note with [Kubernetes Release Notes Generator](https://github.com/kubernetes/release/blob/master/cmd/release-notes/README.md). See the following `Release note creation` section for the details.
1. Before tagging `vX.Y.Z`, run GitLab `daily-ci` for the release commit and verify the pipeline's commit SHA matches. Link the pipeline in the release issue and review any jobs marked `allow_failure`.
1. An approver creates [new release in GitHub](https://github.com/kubernetes-sigs/kubespray/releases/new) using a version and tag name like `vX.Y.Z` and attaching the release notes
1. (Only for major releases) An approver creates a release branch in the form `release-X.Y`
1. (For major releases) On the `master` branch: bump the version in `galaxy.yml` to the next expected major release (X.y.0 with y = Y + 1), make a Pull Request.