最新：获取项目更新 推特 和 Mastodon

发布流程

本文档旨在概述为 cert-manager 切割新版本而应遵循的流程。如果您想了解有关当前版本的更多信息以及未来版本的发布时间表，请查看 支持的版本 页面。

先决条件

⛔️ 如果不满足以下所有条件，请不要继续发布流程

  1. 您要执行的发布的 testgrid 仪表板 不应该出现故障。

  2. 你正在尝试发布的分支必须通过 cert-manager govulncheck GitHub 操作。如有必要，请在本地运行 make verify-govulncheck。

  3. 发布流程大约需要 40 分钟。你需要有足够的时间完成所有步骤。

  4. 你需要在 cert-manager 项目中拥有 GitHub admin 权限。要检查你是否拥有 admin 角色，请运行

    brew install gh
    gh auth login
    gh api /repos/cert-manager/cert-manager/collaborators/$(gh api /user | jq -r .login)/permission | jq .permission

    如果你的权限是 admin，那么你就可以开始了。要申请 cert-manager 项目的 admin 权限，请创建一个 PR，并添加指向此处的链接。

  5. 你需要被添加为 GCP 项目 cert-manager-release 的“编辑者”。要检查你是否有访问权限，请尝试打开 Cloud Build 页面。要获得 GCP 项目的“编辑者”权限，你需要成为维护者。如果你已经是维护者，请创建一个 PR，并将你的电子邮件地址添加到 variables.tf 中的发布经理列表中。

    你可以使用以下 PR 描述

    Title: Access to the cert-manager-release GCP project
    

    Hi. As stated in "Prerequisites" on the [release-process][1] page,
    I need access to the [cert-manager-release][2] project on GCP in
    order to perform the release process. Thanks!
    

    [1]: https://cert-manager.k8s.ac.cn/docs/contributing/release-process/#prerequisites
    [2]: https://console.cloud.google.com/?project=cert-manager-release

本指南适用于使用 make 发布的 cert-manager 版本，即从 cert-manager 1.8 及更新的版本。

如果你需要发布 cert-manager 1.7 或更早的版本，请参阅 较早的版本。

工具设置

首先，确保你拥有执行 cert-manager 发布所需的所有工具。

  1. 安装 release-notes CLI。

    go install k8s.io/release/cmd/release-notes@v0.13.0

  2. 安装我们的 cmrel CLI。

    go install github.com/cert-manager/release/cmd/cmrel@latest

  3. 克隆 cert-manager/release 仓库。

    # Don't clone it from inside the cert-manager repo folder.
    git clone https://github.com/cert-manager/release
    cd release

  4. 安装 gcloud CLI。

  5. 登录 gcloud。

    gcloud auth application-default login

  6. 确保 gcloud 指向 cert-manager-release 项目。

    gcloud config set project cert-manager-release
    export CLOUDSDK_CORE_PROJECT=cert-manager-release # this is used by cmrel

  7. 获取一个 GitHub 访问令牌 此处，不选择任何范围。它仅由 release-notes CLI 使用，以避免 API 速率限制，因为它会逐个遍历所有 PR。

小版本发布

小版本发布是向后兼容的“功能”发布。它可以包含新功能和错误修复。

发布版本的流程

🔰 如果某个步骤缺失或过时，请点击此页面右上角的编辑此页面按钮。

  1. 通过查看以下表格来了解我们的发布术语。这将让你知道根据步骤的标题来跳过哪些步骤，例如，（仅限最终发布）意味着此步骤仅在进行最终发布时执行。

    发布类型git 标签示例
    初始 alpha 版本v1.3.0-alpha.0
    后续 alpha 版本v1.3.0-alpha.1
    初始 beta 版本v1.3.0-beta.0
    后续 beta 版本v1.3.0-beta.1
    最终版本v1.3.0
    （可选）补丁预发布版本1v1.3.1-beta.0
    补丁版本（或“点版本”）v1.3.1

  2. 通过在你的 shell 表格中复制以下代码段来设置 4 个环境变量

    export RELEASE_VERSION="v1.3.0-alpha.0"
    export START_TAG="v1.2.0"
    export END_REV="release-1.3"
    export BRANCH="release-1.3"

    注意：要帮助你填写正确的值，请使用以下示例

    变量示例 1示例 2示例 2示例 3示例 4
    初始 alpha后续 alphabeta 版本最终版本补丁版本
    RELEASE_VERSIONv1.3.0-alpha.0v1.3.0-alpha.1v1.3.0-beta.0v1.3.0v1.3.1
    START_TAGv1.2.0v1.3.0-alpha.0v1.3.0-alpha.1v1.2.0*v1.3.0
    END_REVmastermasterrelease-1.3release-1.3release-1.3
    BRANCHmastermasterrelease-1.3release-1.3release-1.3

    *此处不要使用补丁（例如，不要使用 v1.2.3）。它必须是 v1.2.0：你必须使用属于你正在发布的发布分支的最新标签；在上面的示例中，发布分支是 release-1.3，该分支上的最新标签是 v1.2.0。

    注意：这 4 个变量在 release-notes 工具的 README 中进行了描述。为了方便起见，以下表格总结了你需要知道的内容

    变量描述
    RELEASE_VERSIONgit 标签
    START_TAG*“先前”* 版本的 git 标签
    END_REV你的发布分支名称（包含）
    BRANCH你的发布分支名称

  3. （仅限最终发布）准备网站“升级说明”PR。

    确保 cert-manager/website 上有一个包含新升级文档的 PR 准备合并。例如，请参阅 upgrading-1.0-1.1。

  4. （最终发布 + 补丁版本）准备网站“发布说明”PR。

    ⚠️ 此步骤可以提前完成。

    以下步骤需要使用 master（最终发布）或 release-1.x（补丁版本）进行。PR 将在发布后合并。

    使用以下说明转到“生成 github-release-description.md”部分（Ctrl+F 并查找 github-release-description.md）。2. 移除“依赖项”部分。3. 对于 Markdown 文件中的每个项目符号，阅读变更日志条目并检查它是否遵循 发布说明指南。如果你发现变更日志条目不符合指南，则

    • 转到该 PR 并编辑 PR 描述，以更改 release-note 块的内容。
    • 返回发布说明页面，并将相同的更改复制到 release-notes.md（或重新生成文件）。

    并将相同的更改复制到 release-notes.md（或重新生成文件）。4. 通过参考之前的发布说明页面来添加“主要主题”和“社区”部分。5. 使用以下命令将 GitHub 问题编号和 GitHub 句柄（例如，#1234 或 @maelvls）替换为实际链接

    sed -E \
      -e 's$#([0-9]+)$[#\1](https://github.com/cert-manager/cert-manager/pull/\1)$g' \
      -e 's$@(\w+)$[@\1](https://github.com/\1)$g' \
      github-release-description.md >release-notes.md

    1. 将 release-notes.md 移至网站仓库

      # From the cert-manager repo.
      mv release-notes.md ../website/content/docs/release-notes-1.X.md

    2. 在 content/docs/manifest.json 中添加一个条目

      {
         "title": "Release Notes",
         "routes": [
      +    {
      +      "title": "v1.12",
      +      "path": "/docs/release-notes/release-notes-1.12.md"
      +    },

    3. 在文件 content/docs/release-notes/README.md 中添加一行。

  5. （最终发布 + 补丁版本）准备网站“更新版本”PR。

    ⚠️ 此步骤可以提前完成。

    在该 PR 中

    1. （最终发布）更新 支持的版本 页面上的“支持的版本”部分。

    2. （最终发布）更新 支持的版本 页面上的“如何确定支持的 Kubernetes 版本”部分。

    3. （最终发布）更新出现在 scripts/gendocs/generate-new-import-path-docs 中的版本。例如

      -LATEST_VERSION="v1.11-docs"
      +LATEST_VERSION="v1.12-docs"
      

      -genversionwithcli "release-1.11" "$LATEST_VERSION"
      +genversionwithcli "release-1.12" "$LATEST_VERSION"

    4. （最新次要版本的最终发布 + 补丁版本）更新 variables.json 文件中的最新 cert-manager 版本变量。

      -"cert_manager_latest_version": "v1.14.2",
      +"cert_manager_latest_version": "v1.14.3",

    5. （仅限最终发布）通过创建一个副本、删除该副本中没有意义进行版本控制的页面以及更新 manifest.json 文件来冻结 docs/ 文件夹。

      export RELEASE=1.15
      cp -r content/docs content/v${RELEASE}-docs
      rm -rf content/v${RELEASE}-docs/{release-notes,contributing}
      sed -i.bak "s|/docs/|/v${RELEASE}-docs/|g" content/v${RELEASE}-docs/manifest.json
      jq < content/v${RELEASE}-docs/manifest.json >/tmp/manifest \
        'del(.routes[0].routes[] | select(.title | test("Releases|Contributing")))'
      mv /tmp/manifest content/v${RELEASE}-docs/manifest.json

    6. （最终发布 + 补丁版本）更新 API 文档 和 CLI 文档

      # From the website repository, on the master branch.
      ./scripts/gendocs/generate

  6. 检查 origin 远程仓库是否正确。为此，请运行以下命令并确保它返回上游 https://github.com/cert-manager/cert-manager.git

    # Must be run from the cert-manager repo folder.
    git remote -v | grep origin

    它应该显示

    origin  https://github.com/cert-manager/cert-manager (fetch)
    origin  https://github.com/cert-manager/cert-manager (push)

  7. 切换到正确的分支

    • （初始 alpha 和后续 alpha）：切换到 master 分支

      git checkout master
      git pull origin master

    • （仅限初始 beta）发布分支尚不存在，因此让我们创建它并将其推送到远程仓库

      # Must be run from the cert-manager repo folder.
      git checkout master
      git pull origin master
      git checkout -b release-1.12 master
      git push origin release-1.12

      GitHub 权限：git push 仅在你在 cert-manager 仓库中拥有 admin GitHub 权限时才能正常工作，以便创建或推送到分支，请参阅 先决条件。如果你没有此权限，则需要创建一个 PR 将 master 合并到发布分支，并等待 PR 检查变为绿色。

    • （后续 beta、补丁版本和最终发布）：切换到发布分支

      git checkout release-1.12
      git pull origin release-1.12

      你不需要快进分支，因为已经使用 /cherry-pick release-1.0 合并了更改。

      关于代码冻结的说明

      第一个 beta 版本开启了一个新的“代码冻结”周期，该周期持续到最终版本发布。在代码冻结之前，我们将 master 上的所有内容快进到发布分支。

      在代码冻结期间，我们将继续像往常一样将 PR 合并到 master 中。

      对于第二次（以及后续）测试版，我们不会将 master 快速合并到发布分支，而只会/cherry-pick release-1.0那些应该包含在后续测试版中的修复。

      对于补丁版本和最终版本，我们不会进行快速合并；相反，我们将使用/cherry-pick release-1.0命令准备这些版本。

    关于分支保护的说明：发布分支受GitHub 分支保护保护，该保护由Prow 自动配置。这可以防止任何人意外将更改直接推送到这些分支，即使是仓库管理员。如果您出于某种原因需要快进发布分支，则应使用GitHub 分支保护 Web UI删除该发布分支的分支保护。这只是允许您更新分支的临时更改。Prow 会在 24 小时内重新应用分支保护。

  8. 在本地创建新版本所需的标签并将其推送到上游（启动 cert-manager 构建）

    echo $RELEASE_VERSION
    git tag -m"$RELEASE_VERSION" $RELEASE_VERSION
    # be sure to push the named tag explicitly; you don't want to push any other local tags!
    git push origin $RELEASE_VERSION

    注意：git push仅在您拥有 cert-manager 仓库的admin GitHub 权限才能创建或推送到分支，请参阅先决条件。如果您没有此权限，您将必须打开一个 PR 将 master 合并到发布分支，并等待 PR 检查变为绿色。

    注意 2：对于 cert-manager 的最新版本，正在推送的标签将触发一个 Google Cloud Build 作业，使用gcb/build_cert_manager.yaml中的步骤启动构建。具有访问 GCP 上 cert-manager-release 项目权限的用户应该能够在GCB 构建历史记录中查看日志。

  9. 仅适用于 (1.12、1.13 和 1.14)

    在此步骤中，我们确保 Go 模块github.com/cert-manager/cert-manager/cmd/ctl可以被第三方导入。

    首先，创建一个临时分支。

    # Must be run from the cert-manager repo folder.
    git checkout -b "update-cmd/ctl/$RELEASE_VERSION"

    其次，使用我们刚刚创建的标签更新cmd/ctl的go.mod

    # Must be run from the cert-manager repo folder.
    cd cmd/ctl
    go get github.com/cert-manager/cert-manager@$RELEASE_VERSION
    cd ../..
    

    make tidy
    git add "**/go.mod" "**/go.sum"
    git commit --signoff -m"Update cmd/ctl's go.mod to $RELEASE_VERSION"

    然后，将分支推送到您对 cert-manager 的 fork。例如

    # Must be run from the cert-manager repo folder.
    gh repo fork --remote-name fork
    git push -u fork "update-cmd/ctl/$RELEASE_VERSION"

    然后，打开一个 PR 合并该更改，并使用以下命令返回发布分支

    gh pr create \
      --title "[Release $RELEASE_VERSION] Update cmd/cmctl's go.mod to $RELEASE_VERSION" \
      --body-file - --base $BRANCH <<EOF
    This PR cmd/cmctl's go.mod to $RELEASE_VERSION as part of the release process.
    

    **To the reviewer:** the version changes in \`go.mod\` must be reviewed.
    

    \`\`\`release-note
    NONE
    \`\`\`
    EOF

    等待 PR 被合并。

    最后，为cmd/ctl模块创建一个标签

    # Must be run from the cert-manager repo folder.
     git fetch origin $BRANCH
     git checkout $BRANCH
     git pull --ff-only origin $BRANCH
     git tag -m"cmd/ctl/$RELEASE_VERSION" "cmd/ctl/$RELEASE_VERSION" origin/$BRANCH
     git push origin "cmd/ctl/$RELEASE_VERSION"

    注意：我们之所以需要这样做，在 Stack Overflow 上有解释：如何管理子模块的版本

  10. 在本节中，我们将创建 GitHub 版本的描述。

    注意：此步骤是关于创建将被复制粘贴到 GitHub 版本页面的描述。网站上的“版本说明”页面的创建是在之前的步骤中完成的。

    1. 检查所有 4 个环境变量是否已准备就绪

      echo $RELEASE_VERSION
      echo $START_TAG
      echo $END_REV
      echo $BRANCH

    2. 使用以下命令生成github-release-description.md

      # Must be run from the cert-manager folder.
      export GITHUB_TOKEN=$(gh auth token)
      git fetch origin $BRANCH
      export START_SHA="$(git rev-list --reverse --ancestry-path $(git merge-base $START_TAG $BRANCH)..$BRANCH | head -1)"
      release-notes --debug --repo-path cert-manager \
        --org cert-manager --repo cert-manager \
        --required-author "cert-manager-prow[bot]" \
        --markdown-links=false \
        --output github-release-description.md

      GitHub 令牌不需要任何范围。该令牌仅用于避免对匿名 API 用户施加的速率限制。

    3. 在顶部添加一个句子摘要。

    4. （仅最终版本）编写“社区”部分，遵循过去版本的示例，例如v1.12.0。如果有任何用户没有进行代码贡献，但在其他方面提供了帮助（测试、PR 讨论等），请务必在此处感谢他们！

  11. 检查在您推送标签时自动触发的构建是否已完成，并发送关于该版本的 Slack 消息

    1. 向#cert-manager-dev发送第一条 Slack 消息

      发布 1.2.0-alpha.2 🧵

    2. 检查构建是否已在GCB 构建历史记录中完成。

      🔰 请快速查看构建日志，因为它可能包含一些我们忘记隐藏的未经处理的数据。我们努力确保敏感数据被妥善处理，但有时我们会忘记更新它。

    3. 复制构建日志 URL，并在回复第一条消息的第二条 Slack 消息中发送 Cloud Build 作业链接。例如，消息可能如下所示

      cmrel makestage 构建日志：https://console.cloud.google.com/cloud-build/builds/7641734d-fc3c-42e7-9e4c-85bfc4d1d547?project=1021342095237

  12. 运行cmrel publish

    1. 执行cmrel publish干运行，以确保所有暂存的资源都有效。运行以下命令

      # Must be run from the "cert-manager/release" repo folder.
      cmrel publish --release-name "$RELEASE_VERSION"

      您可以通过单击此命令输出中的 Google Cloud Build URL 查看进度。

    2. 在构建运行时，回复第一条消息发送第三条 Slack 消息

      关注cmrel publish干运行构建：https://console.cloud.google.com/cloud-build/builds16f6f875-0a23-4fff-b24d-3de0af207463?project=1021342095237

    3. 现在真正发布版本工件。以下命令将工件发布到 GitHub、Quay.io以及我们的helm 图表库

      # Must be run from the "cert-manager/release" repo folder.
      cmrel publish --nomock --release-name "$RELEASE_VERSION"

      ⏰ 完成后将有

      1. GitHub 上的 cert-manager 草稿版本
      2. 包含新 Helm 图表的拉取请求

    4. 在构建运行时，回复第一条消息发送第四条 Slack 消息

      关注 cmrel publish 构建：https://console.cloud.google.com/cloud-build/builds/b6fef12b-2e81-4486-9f1f-d00592351789?project=1021342095237

  13. 发布 GitHub 版本

    1. 访问草稿 GitHub 版本，并粘贴您之前生成的版本说明。您需要手动编辑内容以匹配早期版本的样式。特别是，请记住删除与包相关的更改。

    2. （初始 alpha、后续 alpha 和 beta 版本）选中“这是一个预发布版本”框。

    3. （最终版本和补丁版本）选中“设置为最新版本”框。

    4. 单击“发布”以使 GitHub 版本生效。

  14. 合并包含 Helm 图表的拉取请求

    重要：目前，此 PR 只能由 Venafi 员工合并，但我们正在努力尽快解决此问题。更改此操作将涉及我们制定一项计划，用于迁移我们 Helm 图表的存储位置并确保我们不会破坏任何人。

    cert-manager 的 Helm 图表使用 Cloudflare 页面提供服务，Helm 图表文件和元数据存储在Jetstack 图表库中。cmrel publish --nomock步骤（以上）将在该库中创建一个 PR，您现在必须按照以下步骤审核并合并它

    1. 访问拉取请求
    2. 审核更改
    3. 修复任何失败的检查
    4. 测试图表
      1. 从拉取请求中下载图表 tarball
      2. 启动一个新的本地 Kind 集群kind create cluster --name release
      3. 将 helm 图表安装到 Kind 集群helm install cert-manager ./cert-manager-v0.15.0.tgz --set crds.enabled=true -n cert-manager
      4. 确保安装成功，所有组件都在运行
      5. 拆除 Kind 集群kind delete cluster --name release
    5. 合并 PR
    6. 检查cert-manager Helm 图表是否在 ArtifactHUB 上可见。

  15. （最终版本 + 补丁版本）合并 4 个网站 PR

    1. 合并您之前创建的“版本说明”、“升级说明”和“冻结和更新版本”的 PR。

    2. 通过单击此处创建“将 release-next 合并到 master”的 PR。

      如果您看到标签dco-signoff: no，请在 PR 上添加以下评论

      /override dco

      此命令是必要的，因为一些合并提交是由机器人编写的，并且没有 DCO 签署。

  16. 仅适用于 (1.14 及以下)

    为cmctl的Homebrew 公式更新打开一个 PR。

    ℹ️ 如果您发布了 cert-manager 的latest版本，该 PR 会自动创建，在这种情况下，此步骤可以跳过。但如果您发布了先前版本的补丁，则不会。

    假设您已经安装了brew，您可以使用brew bump-formula-pr命令来执行此操作。您需要新的标签名称和该标签的提交哈希值。有关最新详细信息，请参阅brew bump-formula-pr --help，但命令将采用以下形式

    brew bump-formula-pr --dry-run --tag v0.10.0 --revision da3265115bfd8be5780801cc6105fa857ef71965 cmctl

    用新的标签和修订替换它们。

    这将需要 Homebrew 团队进行审查。一旦针对https://github.com/homebrew/homebrew-core的拉取请求打开，请继续执行其他发布步骤。

  17. 将 Slack 消息发布为对第一条消息的答复。切换“也发送到#cert-manager-dev”复选框，以便该消息清晰可见。还请将该消息交叉发布到#cert-manager。

    https://github.com/cert-manager/cert-manager/releases/tag/v1.0.0 🎉

  18. （仅最终版本）向全世界展示该版本

    1. 向cert-manager-dev@googlegroups.com发送带有release标签的电子邮件（示例）。

    2. 在 cert-manager Twitter 帐户上发送一条推文！登录详细信息在 Jetstack 的 1password 中（暂时）。（示例推文）。确保@JetstackHQ 转发它！

    3. 从 cert-manager Mastodon 帐户发送一条嘟嘟！登录详细信息在 Jetstack 的 1password 中（暂时）。（示例嘟嘟）

  19. 继续进行发布后的“测试和发布”步骤

    1. （仅限初始测试版）在 cert-manager/testing 上创建一个 PR，以便将新版本添加到我们定期 ProwJobs 的列表中。使用 此 PR 作为示例。您需要运行 make prowgen 命令来生成新的配置。

    2. （仅限最终版本）在 cert-manager/testing 上创建一个 PR，从 prow 配置中移除任何不受支持的版本。

    3. （仅限最终版本）在 cert-manager/testing 中检查 milestone_applier 配置，以便在 master 上新创建的 PR 应用于下一个版本的新的里程碑。

      还要检查发布分支的必需状态检查和 testgrid 仪表板配置。

      如果下一个版本的 里程碑 不存在，请先创建它。如果您认为您刚刚发布的版本的里程碑已完成，请将其关闭。

    4. 针对 Krew 索引打开一个 PR，例如 此 PR，升级我们 kubectl 插件的版本。这可能只在 cmctl / kubectl 插件功能发生重大变化或在新主版本的首次发布之后才值得。

    5. 创建一个新的 OLM 包并发布到 OperatorHub

      cert-manager 可以使用 Operator Lifecycle Manager (OLM) 安装，因此我们需要为每个 cert-manager 版本创建 OLM 包，并将它们发布到 operatorhub.io 和 RedHat OpenShift 的等效软件包索引。

      按照 cert-manager OLM 发布流程 进行操作，并在发布后 验证 cert-manager OLM 安装说明 是否仍然有效。

旧版本

以上指南仅适用于 v1.8 及更高版本的 cert-manager。

旧版本使用 Bazel 构建，这种构建过程的差异反映在发布过程中。

cert-manager 1.6 和 1.7

请遵循 GitHub 上的 此旧版本 的发布流程，而不是此网站上的指南。

最显着的区别是您将调用 cmrel stage 而不是 cmrel makestage。您可以使用最新版本的 cmrel 来进行发布。

cert-manager 1.5 及更早版本

如果您发布的是 1.5 或更早的版本，您还必须确保安装不同的版本的 cmrel。

在您安装 cmrel 的步骤中，您将需要运行以下命令而不是它

go install github.com/cert-manager/release/cmd/cmrel@cert-manager-pre-1.6

这将确保您使用的 cmrel 版本与您发布的 cert-manager 版本兼容。

此外，当您签出 cert-manager/release 存储库时，您应该确保在该存储库中签出 cert-manager-pre-1.6 标签

git checkout cert-manager-pre-1.6

除了不同的 cert-manager/release 标签和 cmrel 版本之外，您可以遵循与 1.6 和 1.7 相同的 旧发布文档 - 只需记住更改您安装的 cmrel 版本！

脚注

  1. 可以创建一个或多个“修补程序预发布版”，以允许在修补程序普遍可用之前，自愿进行社区测试以修复错误或安全问题。修补程序预发布版必须使用 -beta 后缀。↩