etcd 新版本发布流程怎么走release.sh、DRY_RUN 与 GitHub 发布页【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd这篇文章面向需要执行 etcd 版本发布的人release 团队成员。目标很明确在打好所有准备之后用仓库自带的 scripts/release.sh 完成二进制与镜像构建、上传到gs://etcd和容器镜像仓库并生成 GitHub 上的 draft release最后人工到发布页检查后发布。整个流程以 Documentation/contributor-guide/release.md 为准脚本行为以 scripts/release.sh 源码为准。前提一次性准备工作与发布日检查release.md 把前置条件分为两类。以下是一次性操作不需要每个版本都执行生成 GPG key 并添加到 GitHub 账号设置页的 keys 入口。发布脚本假设 git tag 用 GPG 签名。一台 Linux 机器装有 git、Golang 和 dockerGolang 版本必须与仓库 .go-version 一致当前仓库该文件为1.26.6非特权用户能执行 docker 命令机器至少有 5GB 空闲空间。安装 gsutil选择云项目etcd-development。认证镜像仓库gcloud auth login然后gcloud auth configure-docker。安装ghCLI确保gh auth login成功、gh auth status无异常。发布日当天还要验证镜像仓库登录docker login gcr.io docker login quay.io如果发布人没有 1password 访问权限release.md 说明需要由 ahrtr、ivanvc、jmhbnz、serathius 中的一位通过 1password 共享条目把quay.io密码共享给发布人有效期建议设为 1 小时。另外release.md 指出发布至少提前一天要做两件事开一个 issue 公布发布计划提一个kubernetes/orgPR 确保发布团队成员在 etcd 的 release GitHub team 里。用 DRY_RUN 先做一次干跑scripts/release.sh 的默认行为就是干跑DRY_RUN${DRY_RUN:-true}即不显式设置时DRY_RUNtrue。干跑会完整走克隆仓库、构建、生成SHA256SUMS的流程但所有真正改变外部状态的动作都只打印不执行。对照源码干跑具体跳过的是推送版本号提交到远端git push走maybe_runDRY_RUN 时只打印构建阶段强制NO_DOCKER_PUSH1不推送 docker 镜像不执行gsutil上传验证二进制版本时改从本地./release/拷贝 tar 包不创建 GitHub release脚本结尾会打印警告如果不是 DRY 模式却跳过了--no-gh-release需要手动完成 GitHub release。干跑命令${VERSION}换成不带v前缀的版本号例如3.5.13DRY_RUNtrue BRANCH${BRANCH} ./scripts/release.sh ${VERSION}release.md 特别强调干跑会在/tmp下创建目录正式 release 前必须删除这个目录不要遗漏。还有一个用于本地分支测试的干跑示例来自脚本 help 文本在任意未提交的分支上测试DRY_RUNtrue REPOSITORY$(pwd) BRANCHlocal-branch-name ./scripts/release.sh 3.5.0-foobar.2注意--in-place标志在当前分支构建而不克隆远端仓库只能搭配DRY_RUNtrue使用DRY_RUNfalse时脚本会直接报错退出。正式发布克隆目标分支并执行 release.shrelease.md 给出的正式发布步骤git clone --branch release-3.X gitgithub.com:etcd-io/etcd.git cd etcd DRY_RUNfalse ./scripts/release.sh ${VERSION}${VERSION}是不带v前缀的版本号如3.5.13脚本本身也接受带v的写法会自动去掉。如果是 main 分支的预发布版本例如3.6.0-alpha.2需要显式设置BRANCHmainDRY_RUNfalse BRANCHmain ./scripts/release.sh 3.6.0-alpha.2脚本在不指定BRANCH时默认使用release-major-minor由版本号前两位推导REPOSITORY默认是gitgithub.com:etcd-io/etcd.git。执行后脚本做的事情均来自 scripts/release.sh 源码按顺序是校验版本号必须形如major.minor.patch在/tmp/etcd-release-${VERSION}/etcd克隆目标分支并确认与 origin 同步工作区干净、无分叉检查 Go 版本与 .go-version 一致检查gh已登录--no-gh-release时跳过更新api/version/version.go和各模块 go.mod 的版本定义由 scripts/release_mod.sh 的update_versions_cmd完成运行./scripts/build.sh并用bin/etcd --version核对版本提交version: bump up to ${VERSION}交互式确认后才执行git push推送版本号提交提示Push version bump up to ... [y/N]?为所有 etcd Go 模块打 GPG 签名 tag 并推送push_mod_tags_cmdscripts/release_mod.sh调用 scripts/build-release.sh 构建全部发布二进制与 docker 镜像到release/目录构建镜像前会有确认提示Publish etcd ${RELEASE_VERSION} docker images to registries [y/N]?选 N 则跳过 docker 推送用release/下产物逐个核对etcd --version、etcdctl version、etcdutl version生成SHA256SUMS确认后再用gsutil上传.zip/.tar.gz和SHA256SUMS到gs://etcd/${RELEASE_VERSION}/并设置公开读 ACL提示Upload etcd ... release artifacts to gs://etcd [y/N]?从仓库拉取quay.io/coreos/etcd:${RELEASE_VERSION}和gcr.io/etcd-development/etcd:${RELEASE_VERSION}镜像运行etcd --version核对版本非 DRY_RUN 模式下还会把 tar 包从gs://etcd下载回本地解压核对二进制版本用gh release create创建draft状态的 GitHub releaserelease notes 由 scripts/release_notes.tpl.txt 模板渲染生成然后逐个上传release/下的.tar.gz、.zip和SHA256SUMS带--clobber结尾打印警告给出 draft 的 URL 并要求人工去发布页发布。脚本 help 里还有两条边界说明该脚本不执行 Add API capabilities、Performance testing、Documentation 这些步骤需手动先做也不发送发布通告邮件需手动后做。GitHub 发布页检查 draft 并发布脚本只创建 draft不会替你发布。release.md 给出的操作路径打开 release 脚本输出的draftrelease URL点右上角的编辑铅笔按钮编辑 release检查页面是否合理并核对底部勾选项——release.md 给出的核对标准是v3.4 与 v3.5 无勾选框v3.6 勾选 set as latest releasev3.7 勾选 set as pre-release确认后发布。与脚本行为对应scripts/release.sh 在创建 draft 时main分支自动附加--prereleaserelease-3.5分支自动附加--latest其他分支如release-3.4不附加特殊标记。release.md 的勾选核对文字与脚本自动附加的参数来自不同时期的说明实操时以你在发布页看到的实际勾选项为准与脚本行为互相印证。发布页确认无误并点击发布后这一轮发布才算真正对外可见。发布后的收尾动作release.md 列出的发布后步骤按顺序向 etcd-dev googlegroup 发通告邮件格式参考文档中的示例Hello, etcd v3.4.30 is now public! https://github.com/etcd-io/etcd/releases/tag/v3.4.30 Thanks to everyone who contributed to the release! etcd team以上是文档中的示例格式。发信后需要请邮件列表维护者从 pending 列表中批准并给邮件打上Release标签。更新 changelog 中的发布日期。把 release 链接贴回第 1 步开的 issue 并关闭它。提一个后续kubernetes/orgPR把 release team 恢复为空的 least privilege 状态。如果是新的 major/minor 稳定版本创建新的稳定分支git push origin release-${VERSION_MAJOR}.${VERSION_MINOR}。如有需要重新生成 quay.io 密码例如密码曾共享给非 release team 成员文档建议至少每 3 个月轮换一次。在 Kubernetes 中 bump etcd 版本。release.md 的规则是etcd 3.6 补丁 bump 到 Kubernetes 1.34 及所有更新的 minor 版本含masteretcd 3.5 补丁 bump 到 Kubernetes 1.33 及所有更旧的支持版本。具体操作见 bump_etcd_version_k8s.md。已知问题与失败重跑release.md 的 Release known issues 一节给出了三种情况对应的处理方式二进制上传超时如果二进制没有完整上传到 Google Cloud Storage用同一条命令重跑脚本即可。已上传的产物会被覆盖存储桶不使用对象版本管理不会残留错误文件。镜像推送超时向quay.io或gcr.io推送镜像偶发超时。已知安全的做法是在原命令后追加--no-upload重跑镜像上传会优雅续传。GPG 与 SSH 签名发布脚本假设 tag 用 GPG 签名。如果 git 配置里启用了 SSH commit 签名需要在~/.gitconfig中关闭它、改回 GPG 签名后再执行发布。脚本本身的防呆检查也可以作为核对点版本号格式不符、Go 版本与.go-version不一致、api/version/version.gominor 版本对不上、HEAD 没有带目标版本 tag、工作区不干净脚本都会直接报错退出这些错误信息里都带有期望值与实际值的对照可直接定位。脚本参数速查环境变量 / 标志作用来自脚本源码DRY_RUN默认truefalse才会真正推送、上传和创建 draft releaseBRANCH默认release-major-minormain 分支预发布需显式设mainREPOSITORY默认gitgithub.com:etcd-io/etcd.git本地干跑测试可设为$(pwd)--in-place在当前分支构建而不克隆远端仓库只能配合DRY_RUNtrue--no-docker-push跳过 docker 镜像推送--no-upload跳过向gs://etcd的产物上传--no-gh-release跳过gh登录检查与 GitHub draft release 创建需手动补做完整流程串起来就是一次性环境准备 → 提前一天的 issue 与 team 权限 → 干跑并清理/tmp→ 正式DRY_RUNfalse执行 → 到 GitHub draft 发布页核对勾选并发布 → 通告邮件与收尾。每个环节的验证点etcd --version核对、镜像内版本核对、draft URL 检查都已经内置或写在了 release.md 里照此执行即可走完一次 etcd 新版本发布。【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
