Syft 发布全流程指南从make release触发、多架构产物发布到版本撤回机制【免费下载链接】syftCLI tool and library for generating a Software Bill of Materials from container images and filesystems项目地址: https://gitcode.com/GitHub_Trending/sy/syftsyft 是 Anchore 出品的开源 SBOM软件物料清单生成工具其发布流程高度自动化一次 Release 会同时产出 Git 标签、GitHub Release 归档二进制、多架构容器镜像以及 Homebrew Formula。本文以仓库根目录的 RELEASE.md 为主线结合 .github/workflows/release.yaml、.goreleaser.yaml、.make/main.go 与 cmd/syft/main.go 等源码完整讲解一次 syft 发布从触发、审批、构建、发布到出现问题后撤回的全过程帮助维护者掌握 syft 的发布操作与底层流水线原理。一次 syft Release 包含哪些产物根据 RELEASE.md一次 syft Release 由以下四部分构成新的语义化版本semverGit 标签从main分支当前最新提交tip of main打出一个新的 semver 标签。GitHub Release包含一份变更日志changelog以及归档的二进制资产。容器镜像发布到ghcr.io与 Docker Hubdocker.io并附带多架构镜像清单multi-architecture images manifest。Homebrew tap 更新anchore/homebrew-syft的 Formula 被更新指向最新 GitHub Release 中的资产。理想情况下发布应当尽可能频繁、采用小增量方式。除非有破坏性变更阻塞发布或没有合入任何修复/特性否则推荐的发布节奏是每 12 周一次。创建一次发布两步操作RELEASE.md 明确说明发布流程本身应尽可能自动化整个创建过程只有两步。第 1 步用make release触发新发布在仓库根目录执行make release执行后终端会展示一份预览版 changelog如果你对 changelog 内容满意按y继续如果不满意可以中止发布调整将要包含在发布中的 PR 与 issue 上的标签labels然后重新运行触发命令让 changelog 重新生成。这里“调整 labels”正是 changelog 生成的关键机制syft 的 changelog 由 GitHub PR/issue 的标签驱动归类调整标签即可改变 changelog 的条目与分组。需要说明的是make release并非一个传统意义上的静态 Makefile 目标。仓库根目录的 Makefile 是一个薄封装.DEFAULT: %: go run -C .make . $即任意make target都会转发到 .make/main.go 中定义的 go-make 任务集其中包括来自goreleaser.Tasks()的release、snapshot、ci-release、changelog等任务见 .make/main.go底层对接 goreleaser 工具链。第 2 步Release 管理员在 GitHub Actions 流水线页面上审批触发后必须有 Release 管理员在 GitHub Actions 的 release pipeline 运行页面上批准这次发布。审批通过后发布流水线才会生成全部资产并发布 GitHub Release。这一步是一个人工确认闸门approval gate防止自动化的 changelog 或资产生成在未经授权的情况下直接对外发布。流水线的权限配置environment: release与人工审批环节可在 .github/workflows/release.yaml 中看到。发布流水线的内部结构从源码看.github/workflows/release.yaml 定义的流水线远比“两步操作”复杂理解它可以帮你判断发布卡在哪个环节。它由三个 job 组成1. 版本可用性检查version-availablejobs: version-available: uses: anchore/workflows/.github/workflows/check-version-available.yaml...复用 Anchore 的共享工作流检查指定版本是否可用是否已被占用防止重复打 tag。2. 检查门check-gatecheck-gate: uses: anchore/workflows/.github/workflows/check-gate.yaml... with: checks: [Acceptance tests (Linux), Acceptance tests (Mac), Build snapshot artifacts, CLI tests (Linux), Integration tests, Static analysis, Unit tests]发布前必须确认main分支上的全部质量检查已通过包括单元测试、CLI 测试、集成测试、静态分析、接受测试与快照构建。其设计意图在源码注释中写得很清楚“如果这些检查没有在 main 上验证通过我们就不希望触发发布”。这些检查名称与 .github/workflows/validations.yaml 中的定义对应。可通过skip-checks输入跳过检查门用于紧急修复场景对应!inputs.skip-checks条件。3. 发布 jobrelease发布 job 依赖前两个 jobneeds: [check-gate, version-available]并满足if: ${{ always() needs.version-available.result success !contains(fromJSON([failure, cancelled]), needs.check-gate.result) }}即版本可用检查必须成功检查门只要不是失败或取消即可允许被跳过。发布 job 使用 1632 核、32128GB 内存的 runs-on.com 大机器并挂载 120GB 磁盘以满足多架构镜像 二进制的并行构建需求。其实际执行步骤包括checkout 完整历史fetch-depth: 0便于 goreleaser 生成 changelog 与版本信息Bootstrap 环境复用 .github/actions/bootstrap/action.yaml设置 Docker Buildx多平台镜像需要一个docker-container驱动的 builder默认 runner 无法构建多平台镜像登录 Docker Hub 与 GHCR分别使用ANCHOREOSSWRITE_DH_USERNAME/ANCHOREOSSWRITE_DH_PAT和GITHUB_TOKEN执行make ci-release核心构建发布步骤注入RELEASE_VERSION、TAG_TOKEN推送 tag 用、macOS 签名/公证所需的QUILL_*密钥Apple Developer ID 证书链等、GITHUB_TOKEN创建 Release 用与GITHUB_BREW_TOKEN更新 Homebrew Formula 用生成 SBOM 附件调用anchore/sbom-action对go.mod生成sbom.spdx.json作为发布资产continue-on-error: true失败不阻塞发布。4. 安装脚本发布 jobrelease-install-scriptrelease-install-script: needs: [release] if: ${{ always() (needs.release.result success || github.event.inputs.phase install-script-only) }}复用 Anchore 共享工作流把安装脚本同步到get.anchore.io等 CDNCloudflare R2 / AWS S3保证curl ... | sh安装方式的脚本始终指向最新发布版本。仓库根目录的 install.sh 即是被发布的安装脚本它支持通过VERIFY_SIGN开关启用 cosign 签名校验并内置了VERIFY_SIGN_SUPPORTED_VERSIONv0.104.0首个引入 cosign 签名的最低版本与VERIFY_SIGN_FLAG_VERSIONv1.6.0首个支持-v参数的最低版本两个兼容性门槛。产物矩阵二进制、包管理器与多架构镜像.goreleaser.yaml 定义了发布产物的完整构建矩阵与 RELEASE.md 描述的“GitHub Release 镜像 Homebrew”一一对应。跨平台二进制与版本信息注入builds: - id: linux-build dir: ./cmd/syft goos: [linux] goarch: [amd64, arm64, ppc64le, riscv64, s390x] ldflags: | -w -s -extldflags -static -X main.version{{.Version}} -X main.gitCommit{{.Commit}} -X main.buildDate{{.Date}} -X main.gitDescription{{.Summary}}Linuxamd64 / arm64 / ppc64le / riscv64 / s390x 五个架构静态链接CGO_ENABLED0见 env 段macOSdarwinamd64 / arm64并带有 post hook 使用 quill 做签名与公证notarize快照构建时使用--dry-run与--ad-hocWindowsamd64 / arm64归档格式为 zip其余平台为 tar.gz。版本信息通过 ldflags 注入到 cmd/syft/main.go 中声明的四个变量var ( version internal.NotProvided buildDate internal.NotProvided gitCommit internal.NotProvided gitDescription internal.NotProvided )这些变量随后通过clio.Identification传入 CLI 应用cmd/syft/main.go即syft version命令输出内容的来源。默认值[not provided]定义在 cmd/syft/internal/constants.go。系统包deb 与 rpmnfpms: - license: Apache 2.0 maintainer: Anchore, Inc formats: [rpm, deb]通过 nfpm 同时产出.deb与.rpm两种系统包与 test/install 目录下的安装验证脚本相配套。Homebrew Formula 自动更新brews: - repository: owner: anchore name: homebrew-syft token: {{.Env.GITHUB_BREW_TOKEN}} ids: [darwin-archives, linux-archives]goreleaser 会在发布时自动向anchore/homebrew-syft仓库提交 Formula 更新使其指向本次 Release 的最新资产这正是 RELEASE.md 中“Homebrew tap 更新”这一产物的实现位置。四组 Docker 镜像.goreleaser.yaml 的dockers_v2段一次构建四组镜像覆盖两个仓库anchore/syft与ghcr.io/anchore/syft、五个平台镜像组Dockerfile标签productionrootDockerfilelatest、{{.Tag}}nonrootDockerfile.nonrootnonroot、{{.Tag}}-nonrootdebugrootDockerfile.debugdebug、{{.Tag}}-debugdebug-nonrootDockerfile.debug-nonrootdebug-nonroot、{{.Tag}}-debug-nonroot值得注意的实现细节构建基础镜像使用DEBIAN_VERSION: 13注释说明 Debian 13trixie是首个提供 riscv64 distroless 基础镜像的版本同时是 Debian 12 的超集--provenancefalse用于禁用 provenance 证明保持镜像 manifest 干净镜像的 SBOM 由独立步骤产生sbom: false避免与归档产物的 SBOM 重复。归档产物的 SBOM 与 cosign 签名sboms: - artifacts: archive cmd: ../.tool/syft documents: - {{ .Binary }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}.sbom signs: - cmd: .tool/cosign args: - sign-blob ... artifacts: checksum每次发布会用自举的 syft 二进制对每个归档产物扫描生成独立的.sbom文件并用 cosign 通过 Sigstore OIDC 对 checksum 进行无密钥keyless签名。签名产物.sig与.pem证书随 Release 一起发布配合 install.sh 的VERIFY_SIGN校验能力用户可以在安装时验证二进制完整性。撤回一次发布Retracting a release当某次发布被发现有问题时RELEASE.md 给出了标准的撤回步骤删除 GitHub Release将ghcr.io与docker.io注册表中的 docker 镜像取消打标签untag将anchore/homebrew-syft的 brew Formula 回退到指向上一个发布版本在go.mod中为被撤回的版本新增一条retract条目。Go 模块的retract指令是 Go 官方支持的撤回机制在 go.mod当前模块为github.com/anchore/syft中写入形如retract vX.Y.Z的条目后Go 工具链在解析该版本时会给出明确提示引导用户避开有问题的版本。为什么不能删除 Git 标签RELEASE.md 特别强调了一个关键注意点不要从 git 仓库中删除 release 标签tags。原因是发布后的版本可能已经被 Go module proxy如 proxy.golang.org缓存并建立引用。如果删掉标签再重新打同一个版本号新标签的 H1 hashGo 模块校验哈希将与代理缓存中的不一致导致用户拉取新发布时出现校验警告与混淆。因此即使发布有问题也应该保留 Git 标签只通过“删除 GitHub Release untag 镜像 回退 brew Formula go.mod retract”这套组合拳来撤回。发布相关文件索引围绕 syft 发布流程以下仓库文件值得深入阅读RELEASE.md发布流程的权威文档本文主线.github/workflows/release.yamlGitHub Actions 发布流水线定义.goreleaser.yamlgoreleaser 产物矩阵配置二进制/包/镜像/brew/SBOM/签名.make/main.gomake release、make ci-release、make snapshot等任务的 go-make 实现goreleaser 任务接入cmd/syft/main.go版本信息的 ldflags 注入点install.sh随发布同步的安装脚本含 cosign 校验逻辑Taskfile.yamlsnapshot-smoke-test、SNAPSHOT_DIR等发布相关辅助任务与变量Makefile将 make 目标转发到 go-make 的入口。小结syft 的发布流程设计遵循“自动化为主、人工把关”的原则make release一键生成预览 changelog管理员在 GitHub Actions 上审批放行随后由 release 流水线完成跨平台二进制、deb/rpm 包、四组多架构镜像、Homebrew Formula、SBOM 与 cosign 签名等全部产物的构建与发布。同时流程对“失败后的撤回”也做了完整的预案通过删除 GitHub Release、untag 镜像、回退 brew Formula 与go.mod的retract条目组合完成撤回并明确告诫不要删除 Git 标签以免与 Go module proxy 的缓存哈希产生冲突。【免费下载链接】syftCLI tool and library for generating a Software Bill of Materials from container images and filesystems项目地址: https://gitcode.com/GitHub_Trending/sy/syft创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Syft 发布全流程指南从make release触发、多架构产物发布到版本撤回机制【免费下载链接】syftCLI tool and library for generating a Software Bill of Materials from container images and filesystems项目地址: https://gitcode.com/GitHub_Trending/sy/syftsyft 是 Anchore 出品的开源 SBOM软件物料清单生成工具其发布流程高度自动化一次 Release 会同时产出 Git 标签、GitHub Release 归档二进制、多架构容器镜像以及 Homebrew Formula。本文以仓库根目录的 RELEASE.md 为主线结合 .github/workflows/release.yaml、.goreleaser.yaml、.make/main.go 与 cmd/syft/main.go 等源码完整讲解一次 syft 发布从触发、审批、构建、发布到出现问题后撤回的全过程帮助维护者掌握 syft 的发布操作与底层流水线原理。一次 syft Release 包含哪些产物根据 RELEASE.md一次 syft Release 由以下四部分构成新的语义化版本semverGit 标签从main分支当前最新提交tip of main打出一个新的 semver 标签。GitHub Release包含一份变更日志changelog以及归档的二进制资产。容器镜像发布到ghcr.io与 Docker Hubdocker.io并附带多架构镜像清单multi-architecture images manifest。Homebrew tap 更新anchore/homebrew-syft的 Formula 被更新指向最新 GitHub Release 中的资产。理想情况下发布应当尽可能频繁、采用小增量方式。除非有破坏性变更阻塞发布或没有合入任何修复/特性否则推荐的发布节奏是每 12 周一次。创建一次发布两步操作RELEASE.md 明确说明发布流程本身应尽可能自动化整个创建过程只有两步。第 1 步用make release触发新发布在仓库根目录执行make release执行后终端会展示一份预览版 changelog如果你对 changelog 内容满意按y继续如果不满意可以中止发布调整将要包含在发布中的 PR 与 issue 上的标签labels然后重新运行触发命令让 changelog 重新生成。这里“调整 labels”正是 changelog 生成的关键机制syft 的 changelog 由 GitHub PR/issue 的标签驱动归类调整标签即可改变 changelog 的条目与分组。需要说明的是make release并非一个传统意义上的静态 Makefile 目标。仓库根目录的 Makefile 是一个薄封装.DEFAULT: %: go run -C .make . $即任意make target都会转发到 .make/main.go 中定义的 go-make 任务集其中包括来自goreleaser.Tasks()的release、snapshot、ci-release、changelog等任务见 .make/main.go底层对接 goreleaser 工具链。第 2 步Release 管理员在 GitHub Actions 流水线页面上审批触发后必须有 Release 管理员在 GitHub Actions 的 release pipeline 运行页面上批准这次发布。审批通过后发布流水线才会生成全部资产并发布 GitHub Release。这一步是一个人工确认闸门approval gate防止自动化的 changelog 或资产生成在未经授权的情况下直接对外发布。流水线的权限配置environment: release与人工审批环节可在 .github/workflows/release.yaml 中看到。发布流水线的内部结构从源码看.github/workflows/release.yaml 定义的流水线远比“两步操作”复杂理解它可以帮你判断发布卡在哪个环节。它由三个 job 组成1. 版本可用性检查version-availablejobs: version-available: uses: anchore/workflows/.github/workflows/check-version-available.yaml...复用 Anchore 的共享工作流检查指定版本是否可用是否已被占用防止重复打 tag。2. 检查门check-gatecheck-gate: uses: anchore/workflows/.github/workflows/check-gate.yaml... with: checks: [Acceptance tests (Linux), Acceptance tests (Mac), Build snapshot artifacts, CLI tests (Linux), Integration tests, Static analysis, Unit tests]发布前必须确认main分支上的全部质量检查已通过包括单元测试、CLI 测试、集成测试、静态分析、接受测试与快照构建。其设计意图在源码注释中写得很清楚“如果这些检查没有在 main 上验证通过我们就不希望触发发布”。这些检查名称与 .github/workflows/validations.yaml 中的定义对应。可通过skip-checks输入跳过检查门用于紧急修复场景对应!inputs.skip-checks条件。3. 发布 jobrelease发布 job 依赖前两个 jobneeds: [check-gate, version-available]并满足if: ${{ always() needs.version-available.result success !contains(fromJSON([failure, cancelled]), needs.check-gate.result) }}即版本可用检查必须成功检查门只要不是失败或取消即可允许被跳过。发布 job 使用 1632 核、32128GB 内存的 runs-on.com 大机器并挂载 120GB 磁盘以满足多架构镜像 二进制的并行构建需求。其实际执行步骤包括checkout 完整历史fetch-depth: 0便于 goreleaser 生成 changelog 与版本信息Bootstrap 环境复用 .github/actions/bootstrap/action.yaml设置 Docker Buildx多平台镜像需要一个docker-container驱动的 builder默认 runner 无法构建多平台镜像登录 Docker Hub 与 GHCR分别使用ANCHOREOSSWRITE_DH_USERNAME/ANCHOREOSSWRITE_DH_PAT和GITHUB_TOKEN执行make ci-release核心构建发布步骤注入RELEASE_VERSION、TAG_TOKEN推送 tag 用、macOS 签名/公证所需的QUILL_*密钥Apple Developer ID 证书链等、GITHUB_TOKEN创建 Release 用与GITHUB_BREW_TOKEN更新 Homebrew Formula 用生成 SBOM 附件调用anchore/sbom-action对go.mod生成sbom.spdx.json作为发布资产continue-on-error: true失败不阻塞发布。4. 安装脚本发布 jobrelease-install-scriptrelease-install-script: needs: [release] if: ${{ always() (needs.release.result success || github.event.inputs.phase install-script-only) }}复用 Anchore 共享工作流把安装脚本同步到get.anchore.io等 CDNCloudflare R2 / AWS S3保证curl ... | sh安装方式的脚本始终指向最新发布版本。仓库根目录的 install.sh 即是被发布的安装脚本它支持通过VERIFY_SIGN开关启用 cosign 签名校验并内置了VERIFY_SIGN_SUPPORTED_VERSIONv0.104.0首个引入 cosign 签名的最低版本与VERIFY_SIGN_FLAG_VERSIONv1.6.0首个支持-v参数的最低版本两个兼容性门槛。产物矩阵二进制、包管理器与多架构镜像.goreleaser.yaml 定义了发布产物的完整构建矩阵与 RELEASE.md 描述的“GitHub Release 镜像 Homebrew”一一对应。跨平台二进制与版本信息注入builds: - id: linux-build dir: ./cmd/syft goos: [linux] goarch: [amd64, arm64, ppc64le, riscv64, s390x] ldflags: | -w -s -extldflags -static -X main.version{{.Version}} -X main.gitCommit{{.Commit}} -X main.buildDate{{.Date}} -X main.gitDescription{{.Summary}}Linuxamd64 / arm64 / ppc64le / riscv64 / s390x 五个架构静态链接CGO_ENABLED0见 env 段macOSdarwinamd64 / arm64并带有 post hook 使用 quill 做签名与公证notarize快照构建时使用--dry-run与--ad-hocWindowsamd64 / arm64归档格式为 zip其余平台为 tar.gz。版本信息通过 ldflags 注入到 cmd/syft/main.go 中声明的四个变量var ( version internal.NotProvided buildDate internal.NotProvided gitCommit internal.NotProvided gitDescription internal.NotProvided )这些变量随后通过clio.Identification传入 CLI 应用cmd/syft/main.go即syft version命令输出内容的来源。默认值[not provided]定义在 cmd/syft/internal/constants.go。系统包deb 与 rpmnfpms: - license: Apache 2.0 maintainer: Anchore, Inc formats: [rpm, deb]通过 nfpm 同时产出.deb与.rpm两种系统包与 test/install 目录下的安装验证脚本相配套。Homebrew Formula 自动更新brews: - repository: owner: anchore name: homebrew-syft token: {{.Env.GITHUB_BREW_TOKEN}} ids: [darwin-archives, linux-archives]goreleaser 会在发布时自动向anchore/homebrew-syft仓库提交 Formula 更新使其指向本次 Release 的最新资产这正是 RELEASE.md 中“Homebrew tap 更新”这一产物的实现位置。四组 Docker 镜像.goreleaser.yaml 的dockers_v2段一次构建四组镜像覆盖两个仓库anchore/syft与ghcr.io/anchore/syft、五个平台镜像组Dockerfile标签productionrootDockerfilelatest、{{.Tag}}nonrootDockerfile.nonrootnonroot、{{.Tag}}-nonrootdebugrootDockerfile.debugdebug、{{.Tag}}-debugdebug-nonrootDockerfile.debug-nonrootdebug-nonroot、{{.Tag}}-debug-nonroot值得注意的实现细节构建基础镜像使用DEBIAN_VERSION: 13注释说明 Debian 13trixie是首个提供 riscv64 distroless 基础镜像的版本同时是 Debian 12 的超集--provenancefalse用于禁用 provenance 证明保持镜像 manifest 干净镜像的 SBOM 由独立步骤产生sbom: false避免与归档产物的 SBOM 重复。归档产物的 SBOM 与 cosign 签名sboms: - artifacts: archive cmd: ../.tool/syft documents: - {{ .Binary }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}.sbom signs: - cmd: .tool/cosign args: - sign-blob ... artifacts: checksum每次发布会用自举的 syft 二进制对每个归档产物扫描生成独立的.sbom文件并用 cosign 通过 Sigstore OIDC 对 checksum 进行无密钥keyless签名。签名产物.sig与.pem证书随 Release 一起发布配合 install.sh 的VERIFY_SIGN校验能力用户可以在安装时验证二进制完整性。撤回一次发布Retracting a release当某次发布被发现有问题时RELEASE.md 给出了标准的撤回步骤删除 GitHub Release将ghcr.io与docker.io注册表中的 docker 镜像取消打标签untag将anchore/homebrew-syft的 brew Formula 回退到指向上一个发布版本在go.mod中为被撤回的版本新增一条retract条目。Go 模块的retract指令是 Go 官方支持的撤回机制在 go.mod当前模块为github.com/anchore/syft中写入形如retract vX.Y.Z的条目后Go 工具链在解析该版本时会给出明确提示引导用户避开有问题的版本。为什么不能删除 Git 标签RELEASE.md 特别强调了一个关键注意点不要从 git 仓库中删除 release 标签tags。原因是发布后的版本可能已经被 Go module proxy如 proxy.golang.org缓存并建立引用。如果删掉标签再重新打同一个版本号新标签的 H1 hashGo 模块校验哈希将与代理缓存中的不一致导致用户拉取新发布时出现校验警告与混淆。因此即使发布有问题也应该保留 Git 标签只通过“删除 GitHub Release untag 镜像 回退 brew Formula go.mod retract”这套组合拳来撤回。发布相关文件索引围绕 syft 发布流程以下仓库文件值得深入阅读RELEASE.md发布流程的权威文档本文主线.github/workflows/release.yamlGitHub Actions 发布流水线定义.goreleaser.yamlgoreleaser 产物矩阵配置二进制/包/镜像/brew/SBOM/签名.make/main.gomake release、make ci-release、make snapshot等任务的 go-make 实现goreleaser 任务接入cmd/syft/main.go版本信息的 ldflags 注入点install.sh随发布同步的安装脚本含 cosign 校验逻辑Taskfile.yamlsnapshot-smoke-test、SNAPSHOT_DIR等发布相关辅助任务与变量Makefile将 make 目标转发到 go-make 的入口。小结syft 的发布流程设计遵循“自动化为主、人工把关”的原则make release一键生成预览 changelog管理员在 GitHub Actions 上审批放行随后由 release 流水线完成跨平台二进制、deb/rpm 包、四组多架构镜像、Homebrew Formula、SBOM 与 cosign 签名等全部产物的构建与发布。同时流程对“失败后的撤回”也做了完整的预案通过删除 GitHub Release、untag 镜像、回退 brew Formula 与go.mod的retract条目组合完成撤回并明确告诫不要删除 Git 标签以免与 Go module proxy 的缓存哈希产生冲突。【免费下载链接】syftCLI tool and library for generating a Software Bill of Materials from container images and filesystems项目地址: https://gitcode.com/GitHub_Trending/sy/syft创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
