发布流程 ¶

kOps 项目按需发布。流程如下

发布分支 ¶

我们维护一个 release-1.21 分支用于 kOps 1.21.X，release-1.22 用于 kOps 1.22.X，等等。

master 是开发发生的地方。当我们准备发布新的次要版本时，我们会从 master 创建新的分支。当我们准备发布新的 Kubernetes 版本时，我们会尝试推进 master 分支以专注于新功能，并且仅在需要时才将变更 cherry-pick 回发布分支。

通常，我们不鼓励用户运行较旧的 kOps 版本或较旧的分支，因为较新的 kOps 版本应该与较旧的 Kubernetes 版本保持兼容。

Beta 和稳定发布（除了新次要版本的第一個 Beta 版）应该从 release-1.X 分支进行。Alpha 发布可以在 master 或发布分支上进行。

创建新的发布分支 ¶

通常，kOps alpha 发布是从 master 分支创建的，而 beta 和稳定发布是从发布分支创建的。例外情况是新次要版本的第一個 Beta 版：这是次要版本发布分支从 master 分支出来的位置。为了创建新次要版本的第一個 Beta 版以及从 master 分支出来的新的发布分支，请执行以下步骤

更新“下一个”kOps/Kubernetes 次要版本的定期 E2E Prow 作业。
编辑 build_jobs.py 以将新的次要版本添加到 k8s_versions 和 kops_versions 中。还要更新 generate_versions()、generate_pipeline() 和 generate_presubmits_e2e() 中的次要版本列表。
编辑 testgrid config.yaml 以将新的次要版本添加到文件中的两个列表中，并以 kops-k8s- 为前缀。
从每个列表中删除最旧的次要版本。
运行 build_jobs.py 脚本。
在 GitHub 存储库中创建一个新的里程碑。
更新 prow 的 milestone_applier 配置以更新 master 以使用新的里程碑，并为新的功能分支添加条目。将其创建为单独的 PR，因为它需要单独审查。
根据以下部分中的说明创建 .0-beta.1 发布。GitHub Actions 将在标记发布时创建发布分支。
在 master 分支上，创建一个 PR 以更新到下一个次要版本
在 apply_cluster.go 中更新 OldestSupportedKubernetesVersion 和 OldestRecommendedKubernetesVersion
在 upgrade_k8s.md 中为新的次要版本添加一行
修复因现在不受支持的版本而导致的任何测试问题。
为下一个次要版本创建发布说明。发布说明应提及 Kubernetes 支持的移除和弃用。
在 master 上，从分支点开始，为新的次要版本创建第一个 alpha 发布。

创建发布 ¶

发送 Pull Request 以提议发布 ¶

参见 1.22.0-beta.2 PR 以了解示例。

使用 hack/set-version 脚本更新版本，使用新版本作为参数。然后更新黄金测试。

hack/set-version 1.22.0
hack/update-expected.sh

在 macOS 上，可能需要进行一些清理

find . -name "*.bak" -delete

提交更改（但不要推送）

VERSION=$(tools/get_version.sh | grep VERSION | awk '{print $2}')
git checkout -b release_${VERSION}
git add . && git commit -m "Release ${VERSION}"

这是“发布提交”。推送并创建一个 PR。对于 alpha 和“.0-beta.1”发布，应省略基础分支标志 (-B)。

gh pr create -f -l tide/merge-method-squash -B release-1.22

等待 PR 合并。

审查发布提交 PR ¶

要审查其他人的发布提交，请验证以下内容：

在该点需要发布。（例如，没有未修复的阻塞错误。）
提交中除了版本号更新和黄金输出之外没有其他内容。

“verify-versions” CI 任务将确保已在所有预期位置更新了版本。

等待 CI 作业完成 ¶

PR 合并后，GitHub Actions 将标记发布。 staging CI 作业应该从标记构建（来自受信任的 prow 集群，使用 Google Cloud Build）。

它（目前）需要大约 30 分钟才能运行。

提议提升工件 ¶

以下工具是先决条件

目前，我们分别发送镜像和非镜像工件提升 PR。

创建容器提升 PR

cd ${GOPATH}/src/k8s.io/k8s.io

git checkout main
git pull upstream main
git checkout -b kops_images_${VERSION}

echo "" >> registry.k8s.io/images/k8s-staging-kops/images.yaml
echo "# ${VERSION}" >> registry.k8s.io/images/k8s-staging-kops/images.yaml
kpromo cip run --snapshot gcr.io/k8s-staging-kops --snapshot-tag ${VERSION} >> registry.k8s.io/images/k8s-staging-kops/images.yaml

git add -p registry.k8s.io/images/k8s-staging-kops/images.yaml
git commit -m "Promote kOps $VERSION images"

验证，然后发送 PR

gh pr create -f

创建二进制提升 PR

cd ${GOPATH}/src/k8s.io/k8s.io

git checkout main
git pull upstream main
git checkout -b kops_artifacts_${VERSION}

rm -rf ./k8s-staging-kops/kops/releases
mkdir -p ./k8s-staging-kops/kops/releases/${VERSION}/
gsutil rsync -r  gs://k8s-staging-kops/kops/releases/${VERSION}/ ./k8s-staging-kops/kops/releases/${VERSION}/

kpromo manifest files --src k8s-staging-kops/kops/releases/ >> artifacts/manifests/k8s-staging-kops/${VERSION}.yaml

git add artifacts/manifests/k8s-staging-kops/${VERSION}.yaml
git commit -m "Promote kOps $VERSION binary artifacts"

验证，然后发送 PR

gh pr create -f

在批准和合并二进制提升 PR 后，工件将通过 postsubmit 提升到 artifacts.k8s.io。该过程在这里有详细描述。

提升到 GitHub (所有发布) ¶

shipbot 工具来自 kopeio/shipbot.

二进制文件到 github (所有发布)

cd ${GOPATH}/src/k8s.io/kops/
git checkout v$VERSION
shipbot -tag v${VERSION} -config .shipbot.yaml -src ${GOPATH}/src/k8s.io/k8s.io/k8s-staging-kops/kops/releases/${VERSION}/

对发布进行冒烟测试 ¶

此步骤仅对于稳定发布（因为二进制工件不会被提升到 artifacts.k8s.io）才需要。

wget https://artifacts.k8s.io/binaries/kops/${VERSION}/linux/amd64/kops

mv kops ko
chmod +x ko

./ko version

还要运行 kops create cluster 流程，理想情况下验证所有内容都从新位置提取。

发布到 GitHub ¶

下载发布
验证它
通过按“生成发布说明”按钮添加说明
发布它

发布到 Homebrew ¶

此步骤仅对于最新稳定次要版本的稳定发布才需要。

按照文档，我们必须发布与发布兼容的 homebrew 公式。
这应该与发布同时进行，我们将在如何改进此操作的时序方面进行迭代。

使用 CNCF 更新一致性结果 ¶

此步骤仅对于第一个稳定次要版本（“.0”）才需要。

使用以下说明：https://github.com/cncf/k8s-conformance/blob/master/instructions.md

在文档中更新最新的次要发布 ¶

此步骤仅对于第一个稳定次要版本（“.0”）才需要。

创建一个 PR，删除版本发布说明中的“尚未发布”标题。

添加指向发布说明的链接 ¶

此步骤仅在第一个 beta 次要版本（“.0-beta.1”）时才需要。

创建一个更新以下文档的 PR

在 mkdocs.yml 中添加对版本发行说明的引用

更新 alpha 通道和/或稳定通道 ¶

一旦我们确信发布稳定可靠

将 alpha 通道中的 kOps 推荐版本提升

一旦我们确信发布稳定可靠

将稳定通道中的 kOps 推荐版本提升