minikube 二进制发布指南从打 tag 到全平台产物上线的完整流程【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikubeminikube 的版本发布Release是一项高度流程化的工程操作从更新 Kubernetes 版本、构建 ISO 与 kicbase 镜像到生成发布说明、打 git tag、经 Jenkins 构建上传全平台二进制再到合并 releases.json、验证校验和并通知下游包管理器。本文以官方发布文档 binaries.md 为主体骨架结合仓库内 Makefile、hack/tag_release.sh、hack/jenkins/release_build_and_upload.sh 与 release_sanity_test.go 等源码逐阶段还原一次完整发布的执行细节。读完本文你将掌握 minikube 版本发布各阶段的具体操作、参数来源与验证手段可以直接对照仓库复现整个发布链路。发布流程总览一次标准发布按以下顺序推进每一阶段都有明确的前置条件与交付物准备在 Slack#minikube频道公告发布意向暂停合并请求升级依赖更新默认 Kubernetes 版本并合入 PR构建 ISO非补丁版本必须构建新 ISO发布 kicbase 镜像通过 Jenkinskic-release任务完成生成发布说明写入 CHANGELOG.md更新 Makefile 版本号VERSION_MAJOR/VERSION_MINOR/VERSION_BUILD打 tag执行hack/tag_release.sh构建并上传二进制Jenkins Release 任务发布到 GCS 与 GitHub检查日志并合并 releases.json验证校验和、更新文档与公告。其中 beta 版本在完成第 9 步的日志检查后即可视为发布完成正式版本则需走完全部流程。准备阶段环境与仓库状态发布前需要完成三件事在#minikube频道公告发布意向让社区周知暂停合并请求避免新增提交被意外遗漏在 ISO 或发布说明之外本地同时检出两个 minikube 仓库副本你的个人 fork用于提交 PR与上游仓库upstream用于执行发布相关命令。后续所有make类命令均应在上游仓库副本中执行确保基于最新 master 状态操作。更新 Kubernetes 版本在本地上游仓库副本运行make update-kubernetes-version该目标在 Makefile 中声明底层实现位于hack/update/kubernetes_version/目录负责探测最新稳定版 Kubernetes 并同步更新仓库内的默认版本常量与测试清单目录下包含约 20 个版本相关 YAML 与一个 Go 程序见 hack/update/kubernetes_version。运行后检查是否有文件被改动若有则先创建 PR 并合并再继续后续发布步骤。默认 Kubernetes 版本常量定义在 pkg/minikube/constants/constants.go 的DefaultKubernetesVersionMakefile 也正是通过读取该常量来确定编译基准版本。构建新 ISOISO 的发布策略取决于版本类型所有非补丁non-patch版本必须构建新 ISO补丁版本vx.x.1仅当deploy/iso目录自上次发布以来发生过变更时才需要。判断方法在仓库根目录执行git log -- deploy/iso检查是否有新提交。详细的 ISO 发布步骤见同目录文档 iso.md在 Jenkins 的 ISO 任务中填入与 minikube 二进制版本一致的ISO_VERSION、ISO_BUCKET为minikube/iso后构建构建完成后会自动创建携带变更的 PR本地可用hack/jenkins/build_iso.sh脚本先行验证。ISO 构建根目录为 deploy/iso/minikube-iso内含基于 Buildroot 的完整镜像定义。发布新的 kicbase 镜像运行 Jenkins 中的kic-release任务。该任务会自动创建一个 PR必须确认输入正确的版本与仓库信息并手动合并该 PR。kicbase 是驱动 Kind 类集群的容器基础镜像其版本号定义在 pkg/drivers/kic/types.go 的Version字段Makefile 通过读取该常量获得KIC_VERSION。值得注意的是kic-release产出的 kicbase 镜像会以 tarball 形式随发布二进制一并上传在 release_build_and_upload.sh 中脚本读取KIC_VERSION后按amd64、arm64、ppc64le、s390x四种架构执行docker pull/docker image save/openssl sha256生成out/kicbase-版本-架构.tar及其.sha256校验文件。更新发布说明Release Notes在本地上游仓库副本执行make release-notes该目标在 Makefile 中声明实际调用 hack/release_notes.sh。脚本的工作机制如下从gh auth获取 GitHub token存入临时文件并在退出时清理导出为GITHUB_TOKEN供 hack/changelog/changelog.go 使用自动安装github.com/google/pullsheet统计上个 tag 以来的 PR 与评审数据通过git describe --abbrev0定位最近一次 tag驱动 changelog 生成与贡献者名单。将脚本输出粘贴到 CHANGELOG.md 后需要按对终端用户的重要程度排序若变更超过 8 条拆分为Improvements与Bug fixes两部分。同时执行以下清理changelog 只保留面向用户的变更剔除纯文档、低风险重构、仅测试相关的 PR从贡献者名单中移除机器人账号合并名单中重复/相似的名字。该 PR 可以随时合并也可以与后续的Makefile更新 PR 合并提交。更新 Makefile 版本号修改 Makefile 顶部的三个版本变量VERSION_MAJOR ? 1 VERSION_MINOR ? 39 VERSION_BUILD ? 0它们组合出RAW_VERSION$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_BUILD)并进一步导出VERSION ? v$(RAW_VERSION)见 Makefile。该版本号同时被 Windows 安装器生成流程使用out/minikube-installer.exe构建时会将三者替换进 NSIS 模板见 Makefile。⚠️警告只有所有非实验性集成测试全部通过后才允许合并该 PR打 taghack/tag_release.sh版本号合并后执行sh hack/tag_release.sh 1.minor.patch脚本 hack/tag_release.sh 的完整逻辑为校验参数个数用法为tag_release.sh major.minor.build用正则^[0-9]\.[0-9]\.[0-9a-z\.\-]$校验版本格式不匹配即退出在临时目录浅克隆上游仓库checkout master并git pull到最新创建带注释的 taggit tag -a v${version} -m $version Releasegit push origin推送该 tag。该脚本刻意在全新克隆中打 tag以保证 tag 基于干净的上游 master而不是本地未推送的提交。构建并发布二进制此阶段利用刚推送的 git tag将新二进制发布到 GCS 并创建 GitHub Release。操作步骤打开 minikube 的 Release Jenkins 任务并登录点击左侧 ▶️ Build with ParametersVERSION_MAJOR、VERSION_MINOR、VERSION_BUILD填与 Makefile 一致的值获取两个 ISO 校验和并填入参数gsutil cat gs://minikube/iso/minikube-vversion-amd64.iso.sha256 gsutil cat gs://minikube/iso/minikube-vversion-arm64.iso.sha256点击Build。背后的执行脚本是 hack/jenkins/release_build_and_upload.sh它完成了以下关键工作参数自检从VERSION_MAJOR/VERSION_MINOR/VERSION_BUILD拼出版本并用grep校验其与 Makefile 中的声明一致见脚本第 28-38 行防止 tag 与 Makefile 版本漂移环境准备调用check_install_golang.sh与check_install_docker.sh并通过make verify-iso确认 ISO 已存在多平台构建BUILD_IN_DOCKERy make -j 16并行构建 Linux/Darwin 的 amd64 与 arm64 二进制、tar.gz压缩包、Windows 安装器minikube-installer.exe、以及 debamd64/arm64/ppc64el/s390x与 rpmx86_64/aarch64/ppc64le/s390x等全平台产物dirty 校验运行minikube version检查commit:行是否带-dirty后缀若工作区有未提交改动则中止发布脚本第 74-88 行latest 别名复制minikube_latest_amd64.deb等无版本号产物避免每次发布都要更新上游 Kubernetes 文档上传 GCSgsutil -m cp out/* gs://$BUCKET/releases/$TAGNAME/随后将 beta/alpha 之外的正式版本内容复制到gs://$BUCKET/releases/latest/脚本第 126-140 行。检查发布日志任务结束后点击 Console Output 确认发布过程无报错。brew 自动化失败通常在这一步暴露因此日志检查是必经环节。注意如果你发布的是 beta 版本到这里就算完成了。后续步骤仅适用于正式stable版本。合并 releases.json 变更发布脚本会更新https://storage.googleapis.com/minikube/releases.json——该文件是 minikube 二进制进行版本更新检查的数据源且发布后立即生效。minikube-bot 随后会发出一个将 releases.json 变更合入代码树的 PR请及时合并以保持 GCS 与 GitHub 仓库数据同步。仓库内对应产物包括 deploy/minikube/releases.json、deploy/minikube/releases-beta.json 与 deploy/minikube/releases-v2.json更新检查逻辑位于 pkg/minikube/notify。下游包管理器AUR 与 Homebrew Cask发布完成后还需要跟进两个由社区维护的下游包包管理器维护位置发布后动作Arch Linux AURminikube-bin包点击 Flag as package out-of-date 标记过期触发维护者更新Brew CaskHomebrew/homebrew-cask 仓库的 Casks 目录发布任务会自动创建更新版本号与 SHA256 的 PR需人工确认 PR 确实被创建⚠️警告Brew cask 自动化容易出错务必确认 PR 已经创建。验证发布校验和运行make check-release该目标在 Makefile 中实现执行go test -v ./deploy/minikube/release_sanity_test.go -run //版本$$。测试逻辑见 release_sanity_test.goTestReleases会分别从 stable 与 beta 两个 releases JSON 拉取全部版本对应notify.GithubMinikubeReleasesURL等常量逐一验证二进制可下载且校验和正确validateChecksums校验 releases JSON 中 v1 扁平字段与 v2 嵌套 amd64 字段的一致性releaseBinaries将 v1/v2 两种格式归一化覆盖 darwin/linux/windows × amd64/arm/arm64/ppc64le/s390x 的完整矩阵若最终没有任何二进制被检查到测试直接失败no binaries were checked。由于 JSON 有 v1/v2 两种结构make check-release实际验证的是发布产物与 releases.json 记录完全对齐这是发布正确性的最后一道闸门。更新文档与安全元数据文档若本次发布涉及重大变更请向 Kubernetes 官方 minikube 学习环境文档提交更新 PR安全元数据按 OPENSSF Security Insights 规范审阅并更新仓库根目录的 SECURITY-INSIGHTS.yml使其准确反映仓库的构建、供应与安全实践现状。公告新版本最后在 README.md 中提及新版本并通过以下渠道广而告之Slack#minikube频道minikube-dev、minikube-users 邮件列表Twitter目前已由minikube_dev账号自动化发布。小结一次发布的完整清单阶段关键命令 / 操作交付物准备公告、暂停合并、准备 fork upstream干净的发布起点升级 K8smake update-kubernetes-version默认 Kubernetes 版本 PR构建 ISOJenkins ISO 任务ISO_VERSION/ISO_BUCKETminikube/iso带 SHA256 的 ISOkicbase 镜像Jenkinskic-release任务kicbase 镜像 PR发布说明make release-notesCHANGELOG.md 更新版本号编辑 Makefile版本 PR打 tagsh hack/tag_release.sh 1.minor.patch上游 git tag构建上传Jenkins Release 任务含两个ISO_SHA256_*GCS 产物 GitHub Release日志检查Console Output确认 brew 等自动化成功同步数据合并 minikube-bot 的 releases.json PRGCS 与 GitHub 一致验证make check-release全平台校验和通过收尾更新文档与 SECURITY-INSIGHTS.yml、公告社区同步整个流程的核心原则是版本单一来源Makefile 的VERSION_MAJOR/MINOR/BUILD是唯一事实源tag_release.sh与release_build_and_upload.sh都通过正则或 grep 反查它确保 tag、二进制、ISO、releases.json 与 GitHub Release 五者版本完全一致。【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
minikube 二进制发布指南：从打 tag 到全平台产物上线的完整流程
minikube 二进制发布指南从打 tag 到全平台产物上线的完整流程【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikubeminikube 的版本发布Release是一项高度流程化的工程操作从更新 Kubernetes 版本、构建 ISO 与 kicbase 镜像到生成发布说明、打 git tag、经 Jenkins 构建上传全平台二进制再到合并 releases.json、验证校验和并通知下游包管理器。本文以官方发布文档 binaries.md 为主体骨架结合仓库内 Makefile、hack/tag_release.sh、hack/jenkins/release_build_and_upload.sh 与 release_sanity_test.go 等源码逐阶段还原一次完整发布的执行细节。读完本文你将掌握 minikube 版本发布各阶段的具体操作、参数来源与验证手段可以直接对照仓库复现整个发布链路。发布流程总览一次标准发布按以下顺序推进每一阶段都有明确的前置条件与交付物准备在 Slack#minikube频道公告发布意向暂停合并请求升级依赖更新默认 Kubernetes 版本并合入 PR构建 ISO非补丁版本必须构建新 ISO发布 kicbase 镜像通过 Jenkinskic-release任务完成生成发布说明写入 CHANGELOG.md更新 Makefile 版本号VERSION_MAJOR/VERSION_MINOR/VERSION_BUILD打 tag执行hack/tag_release.sh构建并上传二进制Jenkins Release 任务发布到 GCS 与 GitHub检查日志并合并 releases.json验证校验和、更新文档与公告。其中 beta 版本在完成第 9 步的日志检查后即可视为发布完成正式版本则需走完全部流程。准备阶段环境与仓库状态发布前需要完成三件事在#minikube频道公告发布意向让社区周知暂停合并请求避免新增提交被意外遗漏在 ISO 或发布说明之外本地同时检出两个 minikube 仓库副本你的个人 fork用于提交 PR与上游仓库upstream用于执行发布相关命令。后续所有make类命令均应在上游仓库副本中执行确保基于最新 master 状态操作。更新 Kubernetes 版本在本地上游仓库副本运行make update-kubernetes-version该目标在 Makefile 中声明底层实现位于hack/update/kubernetes_version/目录负责探测最新稳定版 Kubernetes 并同步更新仓库内的默认版本常量与测试清单目录下包含约 20 个版本相关 YAML 与一个 Go 程序见 hack/update/kubernetes_version。运行后检查是否有文件被改动若有则先创建 PR 并合并再继续后续发布步骤。默认 Kubernetes 版本常量定义在 pkg/minikube/constants/constants.go 的DefaultKubernetesVersionMakefile 也正是通过读取该常量来确定编译基准版本。构建新 ISOISO 的发布策略取决于版本类型所有非补丁non-patch版本必须构建新 ISO补丁版本vx.x.1仅当deploy/iso目录自上次发布以来发生过变更时才需要。判断方法在仓库根目录执行git log -- deploy/iso检查是否有新提交。详细的 ISO 发布步骤见同目录文档 iso.md在 Jenkins 的 ISO 任务中填入与 minikube 二进制版本一致的ISO_VERSION、ISO_BUCKET为minikube/iso后构建构建完成后会自动创建携带变更的 PR本地可用hack/jenkins/build_iso.sh脚本先行验证。ISO 构建根目录为 deploy/iso/minikube-iso内含基于 Buildroot 的完整镜像定义。发布新的 kicbase 镜像运行 Jenkins 中的kic-release任务。该任务会自动创建一个 PR必须确认输入正确的版本与仓库信息并手动合并该 PR。kicbase 是驱动 Kind 类集群的容器基础镜像其版本号定义在 pkg/drivers/kic/types.go 的Version字段Makefile 通过读取该常量获得KIC_VERSION。值得注意的是kic-release产出的 kicbase 镜像会以 tarball 形式随发布二进制一并上传在 release_build_and_upload.sh 中脚本读取KIC_VERSION后按amd64、arm64、ppc64le、s390x四种架构执行docker pull/docker image save/openssl sha256生成out/kicbase-版本-架构.tar及其.sha256校验文件。更新发布说明Release Notes在本地上游仓库副本执行make release-notes该目标在 Makefile 中声明实际调用 hack/release_notes.sh。脚本的工作机制如下从gh auth获取 GitHub token存入临时文件并在退出时清理导出为GITHUB_TOKEN供 hack/changelog/changelog.go 使用自动安装github.com/google/pullsheet统计上个 tag 以来的 PR 与评审数据通过git describe --abbrev0定位最近一次 tag驱动 changelog 生成与贡献者名单。将脚本输出粘贴到 CHANGELOG.md 后需要按对终端用户的重要程度排序若变更超过 8 条拆分为Improvements与Bug fixes两部分。同时执行以下清理changelog 只保留面向用户的变更剔除纯文档、低风险重构、仅测试相关的 PR从贡献者名单中移除机器人账号合并名单中重复/相似的名字。该 PR 可以随时合并也可以与后续的Makefile更新 PR 合并提交。更新 Makefile 版本号修改 Makefile 顶部的三个版本变量VERSION_MAJOR ? 1 VERSION_MINOR ? 39 VERSION_BUILD ? 0它们组合出RAW_VERSION$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_BUILD)并进一步导出VERSION ? v$(RAW_VERSION)见 Makefile。该版本号同时被 Windows 安装器生成流程使用out/minikube-installer.exe构建时会将三者替换进 NSIS 模板见 Makefile。⚠️警告只有所有非实验性集成测试全部通过后才允许合并该 PR打 taghack/tag_release.sh版本号合并后执行sh hack/tag_release.sh 1.minor.patch脚本 hack/tag_release.sh 的完整逻辑为校验参数个数用法为tag_release.sh major.minor.build用正则^[0-9]\.[0-9]\.[0-9a-z\.\-]$校验版本格式不匹配即退出在临时目录浅克隆上游仓库checkout master并git pull到最新创建带注释的 taggit tag -a v${version} -m $version Releasegit push origin推送该 tag。该脚本刻意在全新克隆中打 tag以保证 tag 基于干净的上游 master而不是本地未推送的提交。构建并发布二进制此阶段利用刚推送的 git tag将新二进制发布到 GCS 并创建 GitHub Release。操作步骤打开 minikube 的 Release Jenkins 任务并登录点击左侧 ▶️ Build with ParametersVERSION_MAJOR、VERSION_MINOR、VERSION_BUILD填与 Makefile 一致的值获取两个 ISO 校验和并填入参数gsutil cat gs://minikube/iso/minikube-vversion-amd64.iso.sha256 gsutil cat gs://minikube/iso/minikube-vversion-arm64.iso.sha256点击Build。背后的执行脚本是 hack/jenkins/release_build_and_upload.sh它完成了以下关键工作参数自检从VERSION_MAJOR/VERSION_MINOR/VERSION_BUILD拼出版本并用grep校验其与 Makefile 中的声明一致见脚本第 28-38 行防止 tag 与 Makefile 版本漂移环境准备调用check_install_golang.sh与check_install_docker.sh并通过make verify-iso确认 ISO 已存在多平台构建BUILD_IN_DOCKERy make -j 16并行构建 Linux/Darwin 的 amd64 与 arm64 二进制、tar.gz压缩包、Windows 安装器minikube-installer.exe、以及 debamd64/arm64/ppc64el/s390x与 rpmx86_64/aarch64/ppc64le/s390x等全平台产物dirty 校验运行minikube version检查commit:行是否带-dirty后缀若工作区有未提交改动则中止发布脚本第 74-88 行latest 别名复制minikube_latest_amd64.deb等无版本号产物避免每次发布都要更新上游 Kubernetes 文档上传 GCSgsutil -m cp out/* gs://$BUCKET/releases/$TAGNAME/随后将 beta/alpha 之外的正式版本内容复制到gs://$BUCKET/releases/latest/脚本第 126-140 行。检查发布日志任务结束后点击 Console Output 确认发布过程无报错。brew 自动化失败通常在这一步暴露因此日志检查是必经环节。注意如果你发布的是 beta 版本到这里就算完成了。后续步骤仅适用于正式stable版本。合并 releases.json 变更发布脚本会更新https://storage.googleapis.com/minikube/releases.json——该文件是 minikube 二进制进行版本更新检查的数据源且发布后立即生效。minikube-bot 随后会发出一个将 releases.json 变更合入代码树的 PR请及时合并以保持 GCS 与 GitHub 仓库数据同步。仓库内对应产物包括 deploy/minikube/releases.json、deploy/minikube/releases-beta.json 与 deploy/minikube/releases-v2.json更新检查逻辑位于 pkg/minikube/notify。下游包管理器AUR 与 Homebrew Cask发布完成后还需要跟进两个由社区维护的下游包包管理器维护位置发布后动作Arch Linux AURminikube-bin包点击 Flag as package out-of-date 标记过期触发维护者更新Brew CaskHomebrew/homebrew-cask 仓库的 Casks 目录发布任务会自动创建更新版本号与 SHA256 的 PR需人工确认 PR 确实被创建⚠️警告Brew cask 自动化容易出错务必确认 PR 已经创建。验证发布校验和运行make check-release该目标在 Makefile 中实现执行go test -v ./deploy/minikube/release_sanity_test.go -run //版本$$。测试逻辑见 release_sanity_test.goTestReleases会分别从 stable 与 beta 两个 releases JSON 拉取全部版本对应notify.GithubMinikubeReleasesURL等常量逐一验证二进制可下载且校验和正确validateChecksums校验 releases JSON 中 v1 扁平字段与 v2 嵌套 amd64 字段的一致性releaseBinaries将 v1/v2 两种格式归一化覆盖 darwin/linux/windows × amd64/arm/arm64/ppc64le/s390x 的完整矩阵若最终没有任何二进制被检查到测试直接失败no binaries were checked。由于 JSON 有 v1/v2 两种结构make check-release实际验证的是发布产物与 releases.json 记录完全对齐这是发布正确性的最后一道闸门。更新文档与安全元数据文档若本次发布涉及重大变更请向 Kubernetes 官方 minikube 学习环境文档提交更新 PR安全元数据按 OPENSSF Security Insights 规范审阅并更新仓库根目录的 SECURITY-INSIGHTS.yml使其准确反映仓库的构建、供应与安全实践现状。公告新版本最后在 README.md 中提及新版本并通过以下渠道广而告之Slack#minikube频道minikube-dev、minikube-users 邮件列表Twitter目前已由minikube_dev账号自动化发布。小结一次发布的完整清单阶段关键命令 / 操作交付物准备公告、暂停合并、准备 fork upstream干净的发布起点升级 K8smake update-kubernetes-version默认 Kubernetes 版本 PR构建 ISOJenkins ISO 任务ISO_VERSION/ISO_BUCKETminikube/iso带 SHA256 的 ISOkicbase 镜像Jenkinskic-release任务kicbase 镜像 PR发布说明make release-notesCHANGELOG.md 更新版本号编辑 Makefile版本 PR打 tagsh hack/tag_release.sh 1.minor.patch上游 git tag构建上传Jenkins Release 任务含两个ISO_SHA256_*GCS 产物 GitHub Release日志检查Console Output确认 brew 等自动化成功同步数据合并 minikube-bot 的 releases.json PRGCS 与 GitHub 一致验证make check-release全平台校验和通过收尾更新文档与 SECURITY-INSIGHTS.yml、公告社区同步整个流程的核心原则是版本单一来源Makefile 的VERSION_MAJOR/MINOR/BUILD是唯一事实源tag_release.sh与release_build_and_upload.sh都通过正则或 grep 反查它确保 tag、二进制、ISO、releases.json 与 GitHub Release 五者版本完全一致。【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
