Docker Machine 版本发布指南：解读 github-release-template 与自动化发布流程-平芜编程栈

运维
云原生

【免费下载链接】docker.machine

Machine management for a container-centric world

项目地址：https://gitcode.com/gh_mirrors/ma/docker.machine

导读

本文围绕 Docker Machine 仓库中面向 GitHub Release 发布场景的模板文档 github-release-template.md 展开，系统讲解该模板的结构、占位符含义，以及配套的 release.sh 发布脚本如何自动完成版本号替换、Changelog 与贡献者名单填充、校验和生成与二进制上传。读完本文，你将掌握 Docker Machine 各版本（含 rc 预发布版）从构建、打包到发布说明撰写与校验的完整方法论，并可将其迁移到同类 Go 命令行项目的发布流程中。

模板在发布流程中的定位

script/release/github-release-template.md是 Docker Machine 的 GitHub Release 说明模板，它本身不包含具体版本数据，而是定义了一套固定的发布说明骨架：安装方式 → Changelog → 致谢贡献者 → 二进制校验和。其中版本号、更新日志、贡献者名单和校验和分别用{{VERSION}}、{{CHANGELOG}}、{{CONTRIBUTORS}}、{{CHECKSUM}}四个占位符标记，由 release.sh 在发布时逐一替换为真实内容。

从 release.sh 可以看到，发布脚本的第一步就是把该模板复制为当前版本的发布说明文件：

cp -f script/release/github-release-template.md "${GITHUB_RELEASE_FILE}"

随后脚本会读取模板内容，并用bash的参数替换语法（${TEMPLATE//\{\{XXX\}\}/$XXX}）依次替换四个占位符（见 release.sh）。也就是说，模板是发布产物在 GitHub 页面上呈现的"底稿"，任何对发布说明格式的调整都应先修改这个模板文件。

模板四段式结构详解

1. 安装章节：为最终用户提供多平台安装命令

模板的第一部分是 Installation（安装），面向的是下载并升级 Docker Machine 的终端用户，覆盖三类主流环境：

Docker Toolbox 一键安装：Mac 与 Windows 用户可以直接通过 Docker Toolbox 获得当前版本的 Docker Machine，同时附带最新版 Docker Engine、Compose 与 Kitematic。这适用于不想手工管理二进制文件的用户。

OS X 命令行安装/升级：

$ curl -L https://github.com/docker/machine/releases/download/{{VERSION}}/docker-machine-`uname -s`-`uname -m` >/usr/local/bin/docker-machine && \ chmod +x /usr/local/bin/docker-machine

该命令利用uname -s（Darwin）与uname -m（x86_64）自动拼出形如docker-machine-Darwin-x86_64的二进制文件名，配合模板中的{{VERSION}}（发布时替换为v0.16.0之类的版本标签）构成完整下载 URL，最后赋予执行权限。

Linux 命令行安装/升级：

$ curl -L https://github.com/docker/machine/releases/download/{{VERSION}}/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && chmod +x /tmp/docker-machine && sudo cp /tmp/docker-machine /usr/local/bin/docker-machine

Linux 版本先将二进制下载到/tmp，赋予执行权限后再sudo拷贝到/usr/local/bin，避免在系统目录上直接以普通用户写文件。

Windows（git bash）安装：

$ if [[ ! -d "$HOME/bin" ]]; then mkdir -p "$HOME/bin"; fi && \ curl -L https://github.com/docker/machine/releases/download/{{VERSION}}/docker-machine-Windows-x86_64.exe > "$HOME/bin/docker-machine.exe" && \ chmod +x "$HOME/bin/docker-machine.exe"

注意 Windows 的二进制命名固定为docker-machine-Windows-x86_64.exe，与 Unix 平台用uname拼接不同。

模板末尾还提示：也可直接从发布页下载任意版本，并指引用户查阅官方安装文档了解更多安装选项。结合 mk/build.mk 中的交叉编译矩阵（VALID_OS_ARCH覆盖 darwin/amd64、linux/amd64、linux/arm、linux/arm64、openbsd/amd64、windows/amd64、windows/386），可以推断这些安装命令中的二进制命名docker-machine-${os}-${arch}正是由build-x目标生成的产物命名规则（mk/build.mk）——这解释了为何下载 URL 与发布页上二进制名称一一对应。

2. Changelog 章节：版本更新内容的聚合区

模板中的 Changelog 章节本身只有一行注释 "Edit the changelog below by hand" 和占位符{{CHANGELOG}}，但它最终承载的是当前版本相对上一个版本的完整提交历史。发布脚本自动填充该占位符的方式见 release.sh：

CHANGELOG=$(git log "${LAST_RELEASE_VERSION}".. --oneline | grep -v 'Merge pull request')

其中LAST_RELEASE_VERSION来自git describe --tags $(git rev-list --tags --max-count=1)（release.sh），即仓库中最近的一个 tag；随后git log以--oneline格式列出两个 tag 之间的全部提交，并过滤掉 merge 提交，避免把分支合并噪音写进发布说明。

仓库根目录的 CHANGELOG.md 展示了手工整理后的最终形态：例如0.16.0 (2018-11-08)版本下按 "General" 与 "Drivers"（amazonec2、openstack 等）分类罗列变更点，如"默认存储驱动升级为 overlay2"、"改进ssh子命令在--native-ssh下的错误报告"等。发布脚本在发布说明生成后，也会提示维护者把 GitHub 上的最终发布说明同步回 CHANGELOG.md（见 release.sh）。

3. Thank You 章节：致谢用户与贡献者

模板的这一段固定向积极用户与贡献者致谢，尤其是提交了详细 bug 报告的用户，并强调"正是你们的努力让 Docker Machine 变得更好"。贡献者名单由占位符{{CONTRIBUTORS}}生成，脚本实现为（release.sh）：

CONTRIBUTORS=$(git log "${LAST_RELEASE_VERSION}".. --format="%aN" --reverse | sort | uniq | awk '{printf "- %s\n", $0 }')

即从上一个 tag 到当前版本之间，提取所有提交的作者名（%aN），经排序去重后按- 作者名的列表格式输出。这让每个在发布窗口内提交过代码的开发者都能在发布说明中获得署名。

4. Checksums 章节：二进制完整性校验

模板末尾的{{CHECKSUM}}占位符是发布安全性的关键一环。发布脚本在构建完成后，对bin/目录下每一个docker-machine-*二进制同时计算 SHA-256 与 MD5 校验和，并组装成结构化列表（release.sh）：

for file in $(ls bin/docker-machine-*); do SHA256=$(openssl dgst -sha256 < "${file}") MD5=$(openssl dgst -md5 < "${file}") LINE=$(printf "\n * **%s**\n * sha256 \`%s\`\n * md5 \`%s\`\n\n" "$(basename ${file})" "${SHA256}" "${MD5}") CHECKSUM="${CHECKSUM}${LINE}" echo "${SHA256} ${file:4}" >> sha256sum.txt echo "${MD5} ${file:4}" >> md5sum.txt done

同一批校验和还会被写入sha256sum.txt与md5sum.txt两个文件，与二进制一起上传到发布页（release.sh），供用户下载后自行比对。这种"发布说明内嵌校验和 + 独立校验和文件"的双重形式，是 Go 二进制分发场景下的常见安全实践。

占位符与发布脚本的完整协作流程

理解模板，还需要知道它由谁、在什么时机被消费。整套发布流水线如下：

校验前置条件：发布脚本要求环境变量GITHUB_TOKEN已设置，且本机装有git、github-release（github-release 命令行工具）、openssl与可用的docker-machine（release.sh）。
版本号校验：版本参数必须匹配^[0-9]\.[0-9]+(\.[0-9])+(-rc[1-9][0-9]*)?$，即形如0.5.1、0.6或0.5.1-rc2（release.sh），rc 预发布版本同样受支持，这与 version/version.go 中RC()函数对rc版本串的识别逻辑相互呼应。
准备构建机器：脚本通过docker-machine status release检查名为release的 VirtualBox 机器，不存在或无法启动时用docker-machine create -d virtualbox --virtualbox-cpu-count=2 --virtualbox-memory=2048 release重建（release.sh），随后eval "$(docker-machine env release)"将 Docker 环境指向该机器。
克隆仓库并升版本号：在release-${VERSION}目录中重新克隆仓库，用sed把 version/version.go 中的Version = "..."改为目标版本并提交（release.sh）。发布脚本还特意注释解释了为何用sed加mv而非sed -i——保证 BSD/GNU sed 跨平台兼容。
容器化构建：执行USE_CONTAINER=true make clean build validate build-x（release.sh）。当USE_CONTAINER=true时，Makefile 会把所有 make 目标转发到 build_in_container.sh 中基于 Dockerfile（golang:1.12.9 基础镜像）启动的构建容器；build-x按 Makefile.inc 中默认的TARGET_OS（darwin/linux/windows）与TARGET_ARCH（amd64/arm/arm64/386）矩阵交叉编译出全平台二进制。
填充模板占位符：依次替换{{VERSION}}、{{CHANGELOG}}、{{CONTRIBUTORS}}、{{CHECKSUM}}，得到完整发布说明github-release-${VERSION}.md。
打 tag 并创建 Release：推送v${VERSION}tag，用github-release release --pre-release创建（预发布）Release，并把描述直接设为刚才生成的发布说明全文（release.sh）。
上传产物：上传所有bin/docker-machine-*二进制以及sha256sum.txt、md5sum.txt（release.sh）。
收尾手工任务：脚本最后明确列出仍需人工完成的事项（release.sh）：在 GitHub 上润色 release notes、把变更清单同步进 CHANGELOG.md、更新文档分支、测试发布页链接的二进制、把 version/version.go 改成下一个开发版本。

模板的实战使用建议

基于模板与脚本的协作方式，可总结出以下实践要点：

发布说明模板与脚本解耦：模板保持纯 Markdown 骨架与占位符，任何格式调整（如新增"已知问题"小节、调整安装命令顺序）只需修改script/release/github-release-template.md，脚本的替换逻辑无需变动。
占位符命名即契约：{{VERSION}}、{{CHANGELOG}}、{{CONTRIBUTORS}}、{{CHECKSUM}}是脚本与模板之间的契约，新增占位符时必须在 release.sh 中同步补充对应的${TEMPLATE//\{\{XXX\}\}/$XXX}替换语句。
校验和务必保留：Checksums 章节既是模板的一部分，也是发布安全性的最低保障；脚本同时产出内嵌列表与独立校验文件，发布后应抽查验证，这也正是脚本收尾清单中"测试发布页链接的二进制"一项的意义。
rc 预发布版本同样走此流程：版本正则允许-rcN后缀，且github-release release显式使用--pre-release，说明候选版本与正式版本共享同一套模板与流水线，区别仅在版本串与预发布标记。