fzf 发布流程全解版本一致性校验、签名标签与 GitHub Actions 自动构建发布【免费下载链接】fzf:cherry_blossom: A command-line fuzzy finder项目地址: https://gitcode.com/GitHub_Trending/fz/fzf本文以 fzf 仓库的发布说明 RELEASE.md 为主线完整拆解 fzf 从版本号同步、make tag一致性校验到标签推送触发 GitHub Actions 发布工作流 的构建、签名、公证与上传全过程。读完后你可以独立执行一次完整的 fzf 版本发布也能在不真正发布的情况下演练并验证整套发布流水线。发布流程总览fzf 的构建、签名、公证notarization与发布publishing全部由 .github/workflows/release.yml 处理工作流的触发条件是tag push——即本地签好标签并推送到远端。完整流程分为四步在master分支上更新六个文件中的版本号并提交用make tag VERSION0.74.3校验文件一致性、签名并推送标签在 Actions 中批准release环境门禁让工作流继续执行GitHub Release 发布完成后将master快进推送到远端。之所以采用先推 tag、后推 master的顺序RELEASE.md 中给出了明确原因只有标签被推送origin上的master仍指向旧版本因此在发布窗口期内/master/install始终解析到已存在的旧版二进制安装脚本不会因版本与制品不匹配而失败。第一步同步更新版本号发布前需要把新版本号写入以下文件并在master上提交以0.74.3为例CHANGELOG.md新版本条目必须位于文件最顶部如0.74.3小节main.go定义var version 0.74的默认值见 main.go#L14-L15正式构建时会通过 ldflags 覆盖install脚本第 5 行version0.74.3硬编码了要下载的版本install.ps1Windows 安装脚本第 1 行$version0.74.3man/man1/fzf.1 与 man/man1/fzf-tmux.1两个 man 页面中均需出现fzf 版本字样。这些文件各自承担不同角色main.go 的version变量是fzf --version的输出来源之一install 和 install.ps1 则按硬编码版本从 release 制品中下载对应二进制install.ps1 下载后还会执行二进制并比对--version输出不一致即报 Invalid version见 install.ps1#L13-L15。因此任何一处漏改都会直接破坏用户侧的安装链路这正是后续一致性校验存在的原因。第二步make tag —— 一致性校验、签名与推送标签完成版本提交后执行make tag VERSION0.74.3make tag会先执行prerelease目标通过一组grep检查版本是否已出现在全部约定位置全部通过后才签名并推送标签。对照 Makefile#L130-L141 可以看到实际检查项prerelease: # Check if version numbers are properly updated grep -q ^$(VERSION_REGEX)$$ CHANGELOG.md grep -qF fzf $(VERSION_TRIM) man/man1/fzf.1 grep -qF fzf $(VERSION_TRIM) man/man1/fzf-tmux.1 grep -qF $(VERSION) install grep -qF $(VERSION) install.ps1 echo OK: all files consistent at $(VERSION) tag: prerelease git tag -s v$(VERSION) -m v$(VERSION) git push origin v$(VERSION)几个值得注意的细节VERSION_REGEX由VERSION_TRIM去掉v前缀和-prerelease后缀见 Makefile#L26-L27逐点转义后生成因此CHANGELOG.md中的标题必须整行精确等于版本号man 页面的检查则要求带引号的形式fzf 0.74.3。标签使用git tag -s签名GPG/SSH 签名保证发布标签可被验证未通过prerelease时标签根本不会被创建和推送。版本号若未显式给出VERSIONMakefile 默认通过git describe --abbrev0从最新标签推导见 Makefile#L18-L25所以直接make tag会作用于最新标签版本显式传参更稳妥。此步骤结束时的状态远端多了一个签名的v0.74.3标签master尚未推送。第三步工作流触发与 release 环境门禁标签推送到远端后.github/workflows/release.yml 立即触发。该工作流的触发与运行配置为on: push: tags: - v* workflow_dispatch: inputs: version: description: Version to validate (e.g. 0.73.0). type: string required: true permissions: contents: write jobs: release: runs-on: macos-latest environment: release要点仅v开头的标签推送会触发真实发布workflow_dispatch手动运行则用于演练见后文测试章节。作业运行在macos-latest上因为需要执行 macOS 签名与公证environment: release使运行暂停在环境门禁需要在 Actions 界面批准后才继续对应 RELEASE.md 第 3 步Approve it in the Actions tab to release。permissions: contents: write只授予写 release 内容所需的最小权限。工作流内部的实际步骤标签推送触发后工作流依次执行以下阶段完整定义见 .github/workflows/release.yml确定版本号标签触发时从GITHUB_REF_NAME去掉v前缀手动触发时取用户输入的version参数。版本一致性复核在 CI 侧重新执行与make prerelease相同的五条grep检查release.yml#L41-L50确保检出的代码树确实对应该版本防止tag 指错了提交这类事故。提取 Release Notes用sed -n /^${R}$/,/^[0-9]/p从 CHANGELOG.md 中截取当前版本小节经反转、去空行、去前两行处理后写入tmp/release-noterelease.yml#L52-L60作为 GitHub Release 的说明文字。运行 goreleaser根据触发方式选择不同参数release.yml#L62-L76触发方式goreleaser 参数效果标签推送真实发布release --clean --release-notes tmp/release-note构建全部制品并创建 GitHub Release手动运行演练release --snapshot --clean --skippublish构建 签名 公证仅跳过 release 上传所需凭据全部来自仓库 SecretsRELEASE_PAT创建 release 的 token、MACOS_SIGN_P12/MACOS_SIGN_PASSWORD签名证书、MACOS_NOTARY_ISSUER_ID/MACOS_NOTARY_KEY_ID/MACOS_NOTARY_KEYApp Store Connect 公证密钥。构建与公证.goreleaser.yml 中的实现goreleaser 的具体行为由根目录的 .goreleaser.yml 定义与发布流程直接相关的部分包括交叉编译矩阵覆盖darwin/linux/windows/freebsd/openbsd/android×amd64/arm/arm64/loong64/ppc64le/s390x/riscv64并排除若干不支持的组合如freebsd/arm、openbsd/riscv64见 .goreleaser.yml#L9-L48版本注入ldflags通过-X main.version{{ .Version }} -X main.revision{{ .ShortCommit }}将版本与提交号写死进 main.go 的version/revision变量.goreleaser.yml#L30-L33这也解释了为什么main.go中的默认值只是占位macOS 签名 公证notarize.macos段以enabled: {{ not .IsSnapshot }}控制——快照构建自动跳过公证真实发布则先用MACOS_SIGN_P12证书签名再用 App Store Connect 密钥执行公证且wait: true阻塞至完成.goreleaser.yml#L51-L84制品格式非 Windows 平台打tar.gzWindows 打zip另通过nfpms生成含 man 页面与 LICENSE 的deb包.goreleaser.yml#L86-L116发布设置prerelease: auto使带预发布后缀的 tag 自动标记为预发布版本快照版本号模板为{{ .Version }}-devel.goreleaser.yml#L118-L126。第四步快进 masterGitHub Release 发布完成后执行git push origin master把master快进到包含新版本号的提交。至此发布窗口结束/master/install开始指向新版本install脚本中的版本与 master 分支源码保持一致。演练发布流程不产生真实 Release 的测试方法RELEASE.md 专门给出了在不触发真实发布的前提下验证流水线的方法非常适合在修改工作流 YAML 或轮换签名凭据后执行在 Actions 标签页点击Release→Run workflow即workflow_dispatch选择一个分支并输入该分支当前对应的版本号——版本一致性检查要求输入值与检出代码树中的文件内容匹配例如 CHANGELOG.md 顶部、install 中的version行按提示批准release环境门禁由于事件不是标签推送goreleaser 以release --snapshot --clean --skippublish运行快照模式下notarize的enabled: {{ not .IsSnapshot }}会跳过公证但构建、签名步骤照常执行仅跳过 GitHub release 上传。该方法可以一次性验证四件事工作流 YAML 语法、版本提取逻辑、macOS runner 环境以及签名/公证凭据是否有效——是发布前成本最低的回归手段。关键文件索引文件在发布流程中的角色RELEASE.md发布流程的操作手册本文主体Makefileprerelease/tag目标的本地实现一致性 grep 检查、签名并推送标签.github/workflows/release.yml标签触发的 CI版本复核、release notes 提取、goreleaser 调用与环境门禁.goreleaser.yml多平台交叉编译、ldflags 版本注入、macOS 签名与公证、制品打包main.goversion/revision变量构建期由 ldflags 覆盖install / install.ps1硬编码待下载版本是版本一致性检查的对象CHANGELOG.md版本条目来源同时被裁剪为 GitHub Release 说明BUILD.md本地构建与测试说明make、make build等与发布流程互为补充适用前提提示上述流程假定开发者持有仓库的推送权限、GPG/SSH 签名密钥以及配置在仓库 Secrets 中的 macOS 签名与公证凭据普通贡献者只需关注提交进入master后版本号相关文件的规范即可。【免费下载链接】fzf:cherry_blossom: A command-line fuzzy finder项目地址: https://gitcode.com/GitHub_Trending/fz/fzf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
fzf 发布流程全解：版本一致性校验、签名标签与 GitHub Actions 自动构建发布
fzf 发布流程全解版本一致性校验、签名标签与 GitHub Actions 自动构建发布【免费下载链接】fzf:cherry_blossom: A command-line fuzzy finder项目地址: https://gitcode.com/GitHub_Trending/fz/fzf本文以 fzf 仓库的发布说明 RELEASE.md 为主线完整拆解 fzf 从版本号同步、make tag一致性校验到标签推送触发 GitHub Actions 发布工作流 的构建、签名、公证与上传全过程。读完后你可以独立执行一次完整的 fzf 版本发布也能在不真正发布的情况下演练并验证整套发布流水线。发布流程总览fzf 的构建、签名、公证notarization与发布publishing全部由 .github/workflows/release.yml 处理工作流的触发条件是tag push——即本地签好标签并推送到远端。完整流程分为四步在master分支上更新六个文件中的版本号并提交用make tag VERSION0.74.3校验文件一致性、签名并推送标签在 Actions 中批准release环境门禁让工作流继续执行GitHub Release 发布完成后将master快进推送到远端。之所以采用先推 tag、后推 master的顺序RELEASE.md 中给出了明确原因只有标签被推送origin上的master仍指向旧版本因此在发布窗口期内/master/install始终解析到已存在的旧版二进制安装脚本不会因版本与制品不匹配而失败。第一步同步更新版本号发布前需要把新版本号写入以下文件并在master上提交以0.74.3为例CHANGELOG.md新版本条目必须位于文件最顶部如0.74.3小节main.go定义var version 0.74的默认值见 main.go#L14-L15正式构建时会通过 ldflags 覆盖install脚本第 5 行version0.74.3硬编码了要下载的版本install.ps1Windows 安装脚本第 1 行$version0.74.3man/man1/fzf.1 与 man/man1/fzf-tmux.1两个 man 页面中均需出现fzf 版本字样。这些文件各自承担不同角色main.go 的version变量是fzf --version的输出来源之一install 和 install.ps1 则按硬编码版本从 release 制品中下载对应二进制install.ps1 下载后还会执行二进制并比对--version输出不一致即报 Invalid version见 install.ps1#L13-L15。因此任何一处漏改都会直接破坏用户侧的安装链路这正是后续一致性校验存在的原因。第二步make tag —— 一致性校验、签名与推送标签完成版本提交后执行make tag VERSION0.74.3make tag会先执行prerelease目标通过一组grep检查版本是否已出现在全部约定位置全部通过后才签名并推送标签。对照 Makefile#L130-L141 可以看到实际检查项prerelease: # Check if version numbers are properly updated grep -q ^$(VERSION_REGEX)$$ CHANGELOG.md grep -qF fzf $(VERSION_TRIM) man/man1/fzf.1 grep -qF fzf $(VERSION_TRIM) man/man1/fzf-tmux.1 grep -qF $(VERSION) install grep -qF $(VERSION) install.ps1 echo OK: all files consistent at $(VERSION) tag: prerelease git tag -s v$(VERSION) -m v$(VERSION) git push origin v$(VERSION)几个值得注意的细节VERSION_REGEX由VERSION_TRIM去掉v前缀和-prerelease后缀见 Makefile#L26-L27逐点转义后生成因此CHANGELOG.md中的标题必须整行精确等于版本号man 页面的检查则要求带引号的形式fzf 0.74.3。标签使用git tag -s签名GPG/SSH 签名保证发布标签可被验证未通过prerelease时标签根本不会被创建和推送。版本号若未显式给出VERSIONMakefile 默认通过git describe --abbrev0从最新标签推导见 Makefile#L18-L25所以直接make tag会作用于最新标签版本显式传参更稳妥。此步骤结束时的状态远端多了一个签名的v0.74.3标签master尚未推送。第三步工作流触发与 release 环境门禁标签推送到远端后.github/workflows/release.yml 立即触发。该工作流的触发与运行配置为on: push: tags: - v* workflow_dispatch: inputs: version: description: Version to validate (e.g. 0.73.0). type: string required: true permissions: contents: write jobs: release: runs-on: macos-latest environment: release要点仅v开头的标签推送会触发真实发布workflow_dispatch手动运行则用于演练见后文测试章节。作业运行在macos-latest上因为需要执行 macOS 签名与公证environment: release使运行暂停在环境门禁需要在 Actions 界面批准后才继续对应 RELEASE.md 第 3 步Approve it in the Actions tab to release。permissions: contents: write只授予写 release 内容所需的最小权限。工作流内部的实际步骤标签推送触发后工作流依次执行以下阶段完整定义见 .github/workflows/release.yml确定版本号标签触发时从GITHUB_REF_NAME去掉v前缀手动触发时取用户输入的version参数。版本一致性复核在 CI 侧重新执行与make prerelease相同的五条grep检查release.yml#L41-L50确保检出的代码树确实对应该版本防止tag 指错了提交这类事故。提取 Release Notes用sed -n /^${R}$/,/^[0-9]/p从 CHANGELOG.md 中截取当前版本小节经反转、去空行、去前两行处理后写入tmp/release-noterelease.yml#L52-L60作为 GitHub Release 的说明文字。运行 goreleaser根据触发方式选择不同参数release.yml#L62-L76触发方式goreleaser 参数效果标签推送真实发布release --clean --release-notes tmp/release-note构建全部制品并创建 GitHub Release手动运行演练release --snapshot --clean --skippublish构建 签名 公证仅跳过 release 上传所需凭据全部来自仓库 SecretsRELEASE_PAT创建 release 的 token、MACOS_SIGN_P12/MACOS_SIGN_PASSWORD签名证书、MACOS_NOTARY_ISSUER_ID/MACOS_NOTARY_KEY_ID/MACOS_NOTARY_KEYApp Store Connect 公证密钥。构建与公证.goreleaser.yml 中的实现goreleaser 的具体行为由根目录的 .goreleaser.yml 定义与发布流程直接相关的部分包括交叉编译矩阵覆盖darwin/linux/windows/freebsd/openbsd/android×amd64/arm/arm64/loong64/ppc64le/s390x/riscv64并排除若干不支持的组合如freebsd/arm、openbsd/riscv64见 .goreleaser.yml#L9-L48版本注入ldflags通过-X main.version{{ .Version }} -X main.revision{{ .ShortCommit }}将版本与提交号写死进 main.go 的version/revision变量.goreleaser.yml#L30-L33这也解释了为什么main.go中的默认值只是占位macOS 签名 公证notarize.macos段以enabled: {{ not .IsSnapshot }}控制——快照构建自动跳过公证真实发布则先用MACOS_SIGN_P12证书签名再用 App Store Connect 密钥执行公证且wait: true阻塞至完成.goreleaser.yml#L51-L84制品格式非 Windows 平台打tar.gzWindows 打zip另通过nfpms生成含 man 页面与 LICENSE 的deb包.goreleaser.yml#L86-L116发布设置prerelease: auto使带预发布后缀的 tag 自动标记为预发布版本快照版本号模板为{{ .Version }}-devel.goreleaser.yml#L118-L126。第四步快进 masterGitHub Release 发布完成后执行git push origin master把master快进到包含新版本号的提交。至此发布窗口结束/master/install开始指向新版本install脚本中的版本与 master 分支源码保持一致。演练发布流程不产生真实 Release 的测试方法RELEASE.md 专门给出了在不触发真实发布的前提下验证流水线的方法非常适合在修改工作流 YAML 或轮换签名凭据后执行在 Actions 标签页点击Release→Run workflow即workflow_dispatch选择一个分支并输入该分支当前对应的版本号——版本一致性检查要求输入值与检出代码树中的文件内容匹配例如 CHANGELOG.md 顶部、install 中的version行按提示批准release环境门禁由于事件不是标签推送goreleaser 以release --snapshot --clean --skippublish运行快照模式下notarize的enabled: {{ not .IsSnapshot }}会跳过公证但构建、签名步骤照常执行仅跳过 GitHub release 上传。该方法可以一次性验证四件事工作流 YAML 语法、版本提取逻辑、macOS runner 环境以及签名/公证凭据是否有效——是发布前成本最低的回归手段。关键文件索引文件在发布流程中的角色RELEASE.md发布流程的操作手册本文主体Makefileprerelease/tag目标的本地实现一致性 grep 检查、签名并推送标签.github/workflows/release.yml标签触发的 CI版本复核、release notes 提取、goreleaser 调用与环境门禁.goreleaser.yml多平台交叉编译、ldflags 版本注入、macOS 签名与公证、制品打包main.goversion/revision变量构建期由 ldflags 覆盖install / install.ps1硬编码待下载版本是版本一致性检查的对象CHANGELOG.md版本条目来源同时被裁剪为 GitHub Release 说明BUILD.md本地构建与测试说明make、make build等与发布流程互为补充适用前提提示上述流程假定开发者持有仓库的推送权限、GPG/SSH 签名密钥以及配置在仓库 Secrets 中的 macOS 签名与公证凭据普通贡献者只需关注提交进入master后版本号相关文件的规范即可。【免费下载链接】fzf:cherry_blossom: A command-line fuzzy finder项目地址: https://gitcode.com/GitHub_Trending/fz/fzf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
