Velero 插件发布流程解析:从 PR 准备、语义化版本定版到镜像构建与 e2e 验证

发布时间:2026/9/17 8:01:25
Velero 插件发布流程解析:从 PR 准备、语义化版本定版到镜像构建与 e2e 验证 Velero 插件发布流程解析从 PR 准备、语义化版本定版到镜像构建与 e2e 验证【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文以 Velero 仓库中的插件发布操作手册 Releasing Velero plugins 为主体完整还原由 Velero 核心维护者负责的官方插件AWS、GCP、Azure、CSI 等从 PR 准备、changelog 归档、打 tag 触发镜像构建到 e2e 验证与 GitHub Release 的完整发布链路。读完本文你可以掌握插件版本号的语义化版本semver决策原则、tag 触发的 CI 镜像构建机制以及 e2e 测试中插件镜像版本的配置位置能够独立完成一次官方插件的正式发布。前置知识Velero 插件只发布镜像不发布二进制Velero 由核心维护者维护的插件不携带任何二进制产物只发布容器镜像因此不需要像 Velero 主仓库那样调用 GoReleaser 脚本。容器镜像通过向插件仓库推送 git tag 触发的 CI 作业自动构建。这一点与 Velero 主仓库的发布方式形成鲜明对比。主仓库需要构建 CLI 二进制因此保留了完整的 GoReleaser 流程见 hack/release-tools/goreleaser.sh该脚本要求设置GITHUB_TOKEN、RELEASE_NOTES_FILE、REGISTRY等环境变量先执行goreleaser check校验配置再通过goreleaser release命令构建并在PUBLISHTRUE时发布到 GitHub。而插件仓库完全没有二进制产物发布动作被简化为打 tag → CI 构建镜像 → 手动创建 Release三步。适用范围Velero 核心团队负责的插件包括 受支持云提供商列表中的全部插件唯独排除 vSphere 插件vSphere 插件的发布流程独立维护。第一步提交 PR 准备插件仓库1. 更新 README 的兼容矩阵与安装说明更新插件仓库的README.md将兼容矩阵compatibility matrix和velero install --plugins安装说明中的版本号改为本次预期发布的版本号并发起 PR。这一步对最终用户至关重要插件的 README 是用户判断某版本插件对应哪个 Velero 版本以及复制安装命令的唯一入口版本号必须与实际 tag 保持一致。2. 按语义化版本确定版本号版本号的确定依据两点语义化版本semver判断本次变更属于不兼容的 API 变更major、向后兼容的功能新增minor还是仅修复patch是否与 Velero 主仓库的接口耦合如果插件使用了 Velero 新引入、修改或移除的方法或变量即插件与 Velero 的pkg/plugin框架 API 发生联动变更版本号的提升级别需要体现这一兼容性变化。可以推断这也解释了为什么插件版本与 Velero 版本在 e2e 测试中成对出现如下一节的镜像矩阵所示——插件镜像与特定 Velero 版本之间存在事实上的兼容约束。3. 归集 changelog将插件仓库中所有未发布的 changelog 片段存放于unreleased/目录每个文件以 PR 编号命名合并为新的CHANGELOG-vversion.md文件删除unreleased/目录内容并按需编辑整理新文件。Velero 主仓库有一套对应的自动化工具可作参考hack/release-tools/changelog.sh 会遍历changelogs/unreleased下的条目按PR号-用户名的文件命名解析出 PR 编号与作者生成形如* 变更描述 (#PR, 作者)的列表提示维护者粘贴到对应 CHANGELOG 文件后执行git rm changelogs/unreleased/*。主仓库的成品格式可参考 changelogs/CHANGELOG-1.17.md其结构为## v版本下依次列出 Download、Container Image如velero/velero:v1.17.0、Documentation、Upgrading 与 Highlights 章节——插件仓库的 changelog 归档思路与之相同只是插件没有二进制下载链接核心信息集中在镜像 tag 上。第二步打 tag 触发镜像构建PR 合并后按以下顺序操作upstream-name可能是upstream或origin取决于本地仓库配置# 1. 检出上游 main 分支 git checkout upstream-name/main # 2. 打版本 tag git tag vversion # 3. 推送 tag触发镜像构建 git push --tags upstream-name推送 tag 后插件仓库的 GitHub Actions 工作流会被触发并自动构建容器镜像。构建进度可在插件仓库自身的 Actions 页面查看。构建完成后需要做两项验证镜像可用性确认新 tag 的镜像已出现在 Docker Hub 的velero/plugin-name仓库中功能正确性使用新镜像运行 Velero 的 e2e 测试。深入 e2e 验证插件版本在哪里配置操作手册特别指出在插件版本被做成可配置之前你必须在测试中手动编辑插件版本。这句提示直接对应本仓库 e2e 框架中的一处硬编码实现。在 test/util/velero/velero_utils.go 中ImagesMatrix是一个以 Velero 版本为一级键、以云厂商aws、azure、gcp、vsphere、csi、datamover为二级键的镜像映射表明确固化了各版本 Velero 所搭配的各插件镜像 tag例如var ImagesMatrix map[string]map[string][]string{ v1.16: { aws: {velero/velero-plugin-for-aws:v1.12.2}, azure: {velero/velero-plugin-for-microsoft-azure:v1.12.2}, gcp: {velero/velero-plugin-for-gcp:v1.12.2}, datamover: {velero/velero-plugin-for-aws:v1.12.2}, velero: {velero/velero:v1.16.2}, ... }, main: { aws: {velero/velero-plugin-for-aws:main}, gcp: {velero/velero-plugin-for-gcp:main}, ... }, }发布新插件版本时的操作含义是如果要针对某个已发布 Velero 版本验证新插件镜像就需要把ImagesMatrix中对应厂商条目的插件 tag 改为新发布的版本如velero/velero-plugin-for-aws:v1.12.2改为新版本这正是手动编辑测试中插件版本的出处。main条目则指向各插件仓库的main分支构建镜像用于日常主干联动测试。e2e 测试的完整执行方式参见 test/e2e/README.md。以 kind 集群 AWS或 MinIO存储为例基本命令为BSL_PREFIXPREFIX_UNDER_BUCKET \ BSL_BUCKETBUCKET_FOR_E2E_TEST_BACKUP \ CREDS_FILE/path/to/aws-creds \ CLOUD_PROVIDERkind \ OBJECT_STORE_PROVIDERaws \ PLUGINSvelero/velero-plugin-for-aws:新插件版本 \ make test-e2e其中PLUGINS变量对应-plugins命令行参数用于显式指定被测插件镜像——发布验证场景下可借此绕过ImagesMatrix的硬编码矩阵直接注入新镜像BSL_CONFIG如BSL_CONFIGregionus-east-1用于传递 BackupStorageLocation 配置README 的故障排查章节也提到若 Velero 日志出现Failed to get bucket region错误即为缺少region配置所致。此外需注意 e2e 测试的几项限制同一轮执行只支持单一云厂商凭据即一次只能测一个厂商的插件迁移类场景需要双集群。这些限制意味着多厂商插件虽然可以共用同一套流程但需要分别安排 e2e 执行。第三步创建正式发布当全部 e2e 测试通过后到插件仓库的 GitHub Releases 页面为新 tag手动创建 Release插件发布没有自动化 Release 步骤这一步由人完成并将新 changelog 文件的内容完整粘贴进 Release 的描述字段作为面向用户的版本说明。全流程速查阶段动作关键产物/验证点PR 准备更新 README 兼容矩阵与velero install说明按 semver Velero 接口变更情况定版unreleased/changelog 合并为CHANGELOG-vversion.md并清空unreleased/一个合并后的 PR打 taggit checkout upstream/main→git tag vversion→git push --tags upstreamCI 作业自动构建镜像镜像验证检查 CI Actions 进度确认 Docker Hubvelero/plugin-name中出现新 tag 镜像镜像可拉取e2e 验证将 test/util/velero/velero_utils.go 中ImagesMatrix的插件 tag 改为新版本按 test/e2e/README.md 的make test-e2e流程执行全量 e2e 通过发布在插件仓库 Releases 页面手动创建 Release粘贴新 changelog 内容作为描述公开可用的版本 Release要点回顾Velero 官方插件只发布容器镜像发布链路为PR 准备 → 打 tag 触发 CI 构建 → e2e 验证 → 手动创建 Release不经过 GoReleaser版本号决策同时受 semver 变更级别和与 Velero 主仓库pkg/plugin接口联动情况双重约束e2e 验证前必须处理 test/util/velero/velero_utils.go 中ImagesMatrix的插件版本硬编码或改用PLUGINS变量注入镜像该流程适用于受支持列表中除 vSphere 插件外的全部 Velero 核心团队插件。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询