Testcontainers for Go 版本发布全指南：基于 DRY_RUN 与 BUMP_TYPE 的自动化发布流程解析

Testcontainers for Go 版本发布全指南基于 DRY_RUN 与 BUMP_TYPE 的自动化发布流程解析【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest本文以 testcontainers-go 仓库中的 RELEASING.md 为骨架系统讲解该项目预发布 正式发布两阶段自动化脚本的完整工作流如何校验版本与远端、如何用DRY_RUN实现发布演练、如何用BUMP_TYPE控制版本号递增策略以及多模块 Git 标签与 Go Module Proxy 的联动机制。读完本文你既能照单执行一次真实的 testcontainers-go 版本发布也能将其多模块发布模式迁移到自己的 Go 项目中。发布前准备版本号与 Git 远端校验Testcontainers for Go 的发布自动化以两个前置条件为起点版本文件必须准确发布所使用的目标版本号来自 internal/version.go 中的Version常量。发布脚本会直接读取并以此为唯一版本来源因此在执行任何发布操作前务必确认该文件内容就是你要发布的版本。例如当前仓库中该文件内容为package internal // Version is the next development version of the application const Version 0.42.0Git 远端必须正确自动化脚本最终会把提交与标签推送到上游仓库github.com/testcontainers/testcontainers-go因此发布前需要确认origin指向正确git remote -v若origin指向的不是目标上游地址推送阶段会失败或推错仓库这一步虽简单但极其关键。第一阶段pre-release.sh —— 只改文件不动 Gitpre-release.sh脚本负责准备发布其核心设计思想是只修改仓库文件、不执行任何 Git 操作从而让发布者可以先审查改动再决定是否真正进入发布阶段。脚本默认启用 dry-run 模式通过DRY_RUN环境变量控制。DRY_RUN默认为开启true只有显式设为false才会真正改写文件DRY_RUNfalse ./scripts/pre-release.sh脚本实际执行的三大类改动更新文档站版本字段修改 mkdocs.yml 中的latest_version字段将其更新为当前版本。例如 dry-run 输出中的sed s/latest_version: .*/latest_version: v0.20.1/g mkdocs.yml mkdocs.yml.tmp mv mkdocs.yml.tmp mkdocs.yml同步各子模块依赖版本testcontainers-go 采用多模块仓库multi-module结构根模块之外的每个 Go 模块都拥有独立的go.mod。脚本会遍历examples与modules目录下的每个模块把其中对 testcontainers-go 的依赖版本统一替换为即将发布的 tagsed s/testcontainers-go v.*/testcontainers-go v0.20.1/g bigtable/go.mod bigtable/go.mod.tmp mv bigtable/go.mod.tmp bigtable/go.mod sed s/testcontainers-go v.*/testcontainers-go v0.20.1/g mysql/go.mod mysql/go.mod.tmp mv mysql/go.mod.tmp mysql/go.mod随后对每个模块依次执行go mod tidy以整理依赖。dry-run 输出中的多行go mod tidy正对应着逐模块整理的调用序列。更新尚未发布模块的文档版本标记对尚未发布过的模块文档将其文档中Not available until the next release以:material-tag: main标识的未发布徽标替换为指向新 release tag 的Since vX.Y.Z徽标sed s/Not available until the next release a href\https:\/\/github.com\/testcontainers\/testcontainers-go\span class\tc-version\:material-tag: main\/span\/a/Since a href\https:\/\/github.com\/testcontainers\/testcontainers-go\/releases\/tag\/v0.20.1\span class\tc-version\:material-tag: v0.20.1\/span\/a/g mysql.md mysql.md.tmp mv mysql.md.tmp mysql.md该步骤会依次处理 couchbase、localstack、mysql、neo4j、postgres、pulsar、redis、redpanda、vault 等模块文档。第二阶段release.sh —— 提交、打标签、推送、触发代理当预发布产生的改动经审查无误后进入正式发布阶段。release.sh同样支持 dry-run默认开启DRY_RUNfalse ./scripts/release.sh正式模式下脚本会依次执行以下操作提交当前状态把pre-release.sh改动过的文件internal/version.go、mkdocs.yml、examples/**/go.*、modules/**/go.*一并提交提交信息形如chore: use new version (v0.20.1) in modules and examples。创建多模块 Git 标签以internal/version.go中的版本值为基础前缀v打标签根模块直接打v0.18.0这类标签examples与modules下的每个子模块按${directory}/${module_name}/${version}命名约定打标签例如examples/mysql/v0.18.0、modules/compose/v0.18.0。递增开发版本更新internal/version.go为下一个开发周期设置新版本号递增幅度由BUMP_TYPE决定。提交并推送在main分支上创建提交信息形如chore: prepare for next minor development cycle (0.21.0)随后git push origin main --tags将分支与全部标签推送到上游。触发 Go Module Proxy通过 curl 请求proxy.golang.org上对应模块的.info端点促使官方代理索引新版本根模块与全部 examples/modules 子模块逐一触发。用 BUMP_TYPE 控制版本递增策略BUMP_TYPE环境变量决定下一个开发版本的递增方式默认值为minor可选值为major、minor、patch传入其他值脚本会直接失败BUMP_TYPEmajor ./scripts/release.sh例如当前版本为v0.18.0时BUMP_TYPEminor默认→ 下一开发版本v0.19.0BUMP_TYPEmajor→ 下一开发版本v1.0.0BUMP_TYPEpatch→ 下一开发版本v0.18.1。注意升级方向是发布 v0.18.0 → 预置 v0.19.0与常规发布后立即 bump patch的习惯不同这是该项目刻意采用的在主分支上预埋下一个 minor 开发版本的节奏。一次完整发布的实际执行日志解读以 v0.20.1 发布为例dry-run 模式下release.sh的完整输出如下$ ./scripts/release.sh Current version: v0.20.1 git add internal/version.go git add mkdocs.yml git add examples/**/go.* git add modules/**/go.* git commit -m chore: use new version (v0.20.1) in modules and examples git tag v0.20.1 git tag examples/bigtable/v0.20.1 git tag examples/datastore/v0.20.1 git tag examples/firestore/v0.20.1 git tag examples/mongodb/v0.20.1 git tag examples/nginx/v0.20.1 git tag examples/pubsub/v0.20.1 git tag examples/spanner/v0.20.1 git tag examples/toxiproxy/v0.20.1 git tag modules/cockroachdb/v0.20.1 git tag modules/compose/v0.20.1 git tag modules/couchbase/v0.20.1 git tag modules/localstack/v0.20.1 git tag modules/mysql/v0.20.1 git tag modules/neo4j/v0.20.1 git tag modules/postgres/v0.20.1 git tag modules/pulsar/v0.20.1 git tag modules/redis/v0.20.1 git tag modules/redpanda/v0.20.1 git tag modules/vault/v0.20.1 WARNING: The requested images platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested Producing a minor bump of the version, from 0.20.1 to 0.21.0 sed s/const Version .*/const Version 0.21.0/g internal/version.go internal/version.go.tmp mv internal/version.go.tmp internal/version.go git add internal/version.go git commit -m chore: prepare for next minor development cycle (0.21.0) git push origin main --tags curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/examples/bigtable/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/examples/datastore/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/examples/firestore/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/examples/mongodb/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/examples/nginx/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/examples/pubsub/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/examples/spanner/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/examples/toxiproxy/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/cockroachdb/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/compose/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/couchbase/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/localstack/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/mysql/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/neo4j/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/postgres/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/pulsar/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/redis/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/redpanda/v/v0.20.1.info curl https://proxy.golang.org/github.com/testcontainers/testcontainers-go/modules/vault/v/v0.20.1.info输出日志值得注意的细节日志中出现了WARNING: The requested images platform (linux/amd64) does not match the detected host platform (linux/arm64/v8)说明脚本内部某些环节涉及 Docker 镜像用于辅助构建或校验在 Apple Silicon 等 arm64 主机上运行 amd64 镜像时可能出现该提示它通常不阻断发布流程但应留意。Producing a minor bump of the version, from 0.20.1 to 0.21.0直观展示了BUMP_TYPEminor时的版本演化发布 0.20.1 后internal/version.go被改写为 0.21.0 并提交。推送完成后通过 curl 逐个命中 proxy.golang.org 的.info端点用于刷新模块缓存使新版本对go get用户立即可见。发布收尾验证上游状态脚本执行完毕后且非 dry-run 模式需要人工确认两件事提交是否已出现在上游仓库的main分支中若没有需将本地main分支的当前状态同步推送到上游各模块的 tagvX.Y.Z与${directory}/${module_name}/${version}是否均已推送成功。这一步是发布质量的最后兜底任何遗漏都会导致部分模块无法被下游通过对应 tag 拉取。仓库中的真实使用场景发布流程如何服务下游项目在 inngest 仓库中testcontainers-go 正是以标准多模块发布产物被消费的根 go.mod 声明依赖github.com/testcontainers/testcontainers-go v0.42.0而 internal/version.go 中的const Version 0.42.0与 mkdocs.yml 中的latest_version: v0.42.0完全一致——这正是上文发布流程中版本文件 → 文档站版本 → 各模块 go.mod三处同步机制生效后的稳定状态可作为验证发布一致性的实例。下游测试基建同样依赖该库的容器编排能力tests/testutil/postgres.go 通过testcontainers.ContainerRequest声明 PostgreSQL 镜像、暴露端口与环境变量并组合wait.ForLog(...)与wait.ForListeningPort(...)构成就绪等待策略再经testcontainers.GenericContainer启动容器、container.MappedPort与container.Host获取映射地址拼接连接串。该文件依赖github.com/testcontainers/testcontainers-go/wait子包而该子包正是随上述多模块 tag 机制发布、可被go get精确拉取的产物之一。小结把发布做成可演练、可审计的自动化流程回顾 testcontainers-go 的发布设计有四点值得借鉴版本单一来源所有自动化读取internal/version.go的Version常量避免版本散落多处导致不一致两阶段分离pre-release.sh只改文件不碰 Gitrelease.sh才执行提交、打标签、推送中间留有审查窗口dry-run 默认开启DRY_RUN默认启用先输出完整执行计划确认无误后再以DRY_RUNfalse真实执行降低误操作风险多模块统一发布根模块与examples/modules下每个子模块分别按目录/模块名/版本约定打 tag并在推送后主动触发 Go Module Proxy 索引保证下游go get立即可用。对于任何采用多模块结构的 Go 项目这套版本文件驱动 dry-run 演练 批量 tag proxy 预热的发布模式都是一份可直接迁移的工程范本。【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考