网络安全应用安全云原生后端【免费下载链接】clairVulnerability Static Analysis for Containers项目地址https://gitcode.com/gh_mirrors/cl/clair点击查看免费下载Clair 是面向容器的漏洞静态分析工具其 v4 系列采用约每三个月发布一次新版本、每个版本积极维护六个月的节奏。本文以仓库内 Documentation/contribution/releases.md 为骨架结合.github/workflows下的自动化流水线、Makefile 与 etc 目录下的构建规则完整还原 Clair 从打 Tag、创建发布分支、生成变更日志到自动产出源码归档、跨平台二进制与多架构容器镜像的端到端流程。读完本文你将掌握作为维护者如何亲手切割 Minor/Patch 版本也能理解发布制品的每一环在仓库中由哪段代码或配置驱动。发布节奏与维护策略Clair 的发布策略非常明确发布周期新版本minor release大约每三个月切割一次维护窗口每个发布的版本被积极维护六个月Bugfix 回流修复类提交应先落在master如果适用然后标记为需要 backport 到某个 minor 版本的发布分支release branch。需要指出的是文档明确说明为 release 分支挑选并移植修复提交的过程目前尚未完全形式化原文The process for doing this is not yet formalized这意味着 backport 依赖维护者的判断与人工操作仓库当前没有对应的自动化机制。这一点从仓库现有 GitHub Actions 列表.github/workflows中也能印证其中只有fast-forward.yml、check-fast-forward.yml这类分支管理辅助工作流并不存在自动 backport 的 workflow。版本切割Minor 与 Patch 两条路线Clair 的版本号遵循语义化版本semver习惯v4.x.0表示 minor 版本v4.x.yy0表示 patch 版本。两类版本的操作流程共用同一套工具链区别只在于是否创建新的发布分支。Minor 版本打 Tag 建分支切割一个新的 minor 版本需要同时完成两件事创建带注释的签名 Tag与创建发布分支。文档给出的标准操作如下git tag -as v4.x.0 HEAD git push upstream HEAD:release-4.x tag v4.x.0拆解来看git tag -as会创建一个 annotated-a且带 GPG 签名-s的标签标签消息中应记录版本号与简要说明。使用 annotated 而非 lightweight tag是为了保证标签对象携带作者、日期与消息便于工具链如git describe正确解析版本信息第二条命令同时推送两条 refHEAD:release-4.x把当前提交推送到名为release-4.x的发布分支例如release-4.9tag v4.x.0推送刚创建的标签。推送完成后还需要在 GitHub UI 中基于该 Tag 手动创建一个 Release。这一步不可省略因为后续所有制品发布流程都以此为触发器见下文制品自动化一节。Patch 版本只在发布分支上打 TagPatch 版本与 minor 版本的唯一区别是minor 版本对应的 Tag 只应出现在发布分支上即release-4.x且 patch 发布不需要新建分支。操作序列为git checkout release-4.x git tag -as v4.x.1 HEAD git push upstream tag v4.x.1注意第三步只推送 Tag不再推送分支。随后同样需要在 GitHub UI 基于新 Tag 创建 Release。这里有一个值得强调的约束minor 版本 Tagv4.x.0应当只存在于release-4.x分支上而不是master/main主线上。结合 prepare-release.yml 中release 分支只筛选同 minor 版本的提交生成 changelog的逻辑见下文这种分支组织方式保证了每个 minor 系列的历史变更记录干净、独立。变更日志Changelog的生成Release 之前的准备工作仓库中存在一个手动触发的辅助工作流 .github/workflows/prepare-release.yml它在正式打 Tag 之前为发布准备CHANGELOG.md。该工作流通过workflow_dispatch接收两个输入branch准备发布所基于的分支默认maintag将要发布的 Tag 名称。工作流使用git-chglog工具按指定标签范围生成变更日志核心逻辑是filter_tag--tag-filter-pattern v4 branch输入的分支名 if [[ ${branch%-*} release ]]; then filter_tag--tag-filter-pattern v${branch#release-} fi也就是说如果目标分支是release-4.x形式的发布分支则只筛选该 minor 版本范围内的提交例如v4.9否则在主线只过滤v4前缀的完整历史。生成完毕后工作流通过peter-evans/create-pull-request自动提交一个标题形如tag Changelog Bump的 PR分支名为ready-tag并启用 sign-off。仓库根目录的 CHANGELOG.md 即这一机制的产物其头部记录着如v4.9.0 - 2025-12-08的版本条目并按All、Amqp、Build(Deps)、Chore、Chore(Deps)等类别分组列出提交。制品自动化一条由 GitHub Release 驱动的流水线Clair 的制品发布过程完全自动化由 GitHub 上的 Release 事件驱动。也就是说维护者在 UI 中点击Publish release的那一刻后续的源码归档生成、容器镜像构建与推送会全部自动完成。驱动的核心是 .github/workflows/cut-release.yml。该工作流的触发条件有两类on: push: tags: - v4.* workflow_dispatch: {}推送v4.*形式的 Tag注意分支推送不会触发只有 Tag push 才会手动触发workflow_dispatch用于演练或补发。整个工作流由 7 个 Job 组成形成一条清晰的依赖链config └─→ release-archive ──→ release-binaries ──→ release ──→ publish-container │ 推送 quay 镜像 └─→ publish-binaries上传 clairctl └─→ deploy-documentation1. config集中计算发布元数据第一个 Job 在quay.io/projectquay/golang:1.25容器中运行从GITHUB_REF推导出所有下游需要的变量version即 Tag 本身如v4.9.0tar_prefixclair-tag/用于源码归档内的顶层目录前缀is_prerelease当 Tag 包含alpha、beta或rc时判定为预发布image_tag去掉v前缀后的镜像 Tag如4.9.0image_repo目标仓库上游自动映射为projectquay/clairbuild_go_version/cache_key由容器内go version推导的构建版本与缓存键。这些输出通过needs: [config]被后续所有 Job 消费。2. release-archive构建完整源码归档该 Job 先以fetch-depth: 0完整检出仓库然后执行git fetch origin ${GITHUB_REF}:${GITHUB_REF} # 修复 checkout action 覆盖 tag 的问题 git archive --prefix clair-tag/ -o clair.tar ${GITHUB_REF} go mod vendor tar -rf clair.tar --transform s,^,clair-tag/, vendor gzip clair.tar mv clair.tar.gz clair-tag.tar.gz关键点在于Clair 的源码归档由git archive生成而不是把工作目录直接打包——这保证了归档内容严格等于 Tag 指向的提交状态不包含任何本地未提交的脏文件。由于go mod vendor生成的vendor目录默认不被 git 跟踪Job 会在归档后把 vendor 目录追加进 tar 包并放到对应的clair-tag/前缀下从而让归档成为一个自包含、可离线构建的完整源码包。该 Job 还会调用git-chglog生成 changelog手动触发时生成空文件占位并把clair-tag.tar.gz与changelog作为clair-releaseartifact 上传。3. release-binaries跨平台编译 clairctl在config产出的 Go 构建镜像中该 Job 通过 matrix 组合goarch × goosarm64/amd64/386/ppc64le/s390x×linux/windows/darwin并排除不支持的组合如 darwin-386、windows-ppc64le 等对./cmd/clairctl执行交叉编译go build -trimpath -ldflags-s -w -buildvcsfalse \ -o clairctl-goos-goarch ./cmd/clairctl-trimpath去除构建路径信息-ldflags-s -w剥离符号表与 DWARF-buildvcsfalse禁用 VCS 信息注入注释指出版本信息应由git archive过程负责。产物按clairctl-goos-goarch命名并作为独立 artifact 上传。4. release创建 GitHub Release该 Job 在push事件下执行通过ncipollo/release-action创建 Release标题为version ReleaseRelease 正文bodyFile使用 changelogprerelease标志来自config的is_prerelease输出将clair-*归档附加为 Release 资产。upload_url作为输出暴露给下游供publish-binaries上传二进制使用。5. publish-container构建并推送多架构容器镜像这是制品分发的重头戏。该 Job 依次执行下载clair-releaseartifact 并解包到临时目录作为构建上下文用docker/setup-qemu-action与docker/setup-buildx-action配置多平台构建能力使用docker/login-action凭QUAY_USER/QUAY_TOKEN登录quay.io通过docker/build-push-action一次构建linux/amd64、linux/arm64、linux/ppc64le、linux/s390x四个平台的镜像并推送platforms: linux/amd64,linux/arm64,linux/ppc64le,linux/s390x push: true tags: | quay.io/image_repo:image_tag即最终镜像会被推送到quay.io/projectquay/clair仓库Tag 为去掉v的版本号如4.9.0与文档中container is pushed to the quay.io/projectquay/clair repository的描述一致。当is_prerelease true时额外调用.github/actions/set-image-expiration为预发布镜像设置过期时间QUAY_API_TOKEN避免 alpha/beta/rc 镜像长期滞留。6. publish-binaries 与 deploy-documentationpublish-binaries将上一步 matrix 产出的所有clairctl-*二进制通过upload-release-asset追加上传到刚创建的 Release作为独立的发布资产deploy-documentation在release完成后触发.github/actions/documentation把文档部署上线——这也解释了仓库中 Documentation 目录作为 mdBook见 etc/doc.mk 的booktarget发布的内容如何随版本更新。本地复现制品构建make dist 与 make dist-container除了完全自动化的 CI 路径维护者也可以在本地手工构建发布制品。文档明确给出了两个命令及其配置来源make dist生成完整的源码归档make dist-container基于该归档生成对应的容器镜像控制这些 target 行为的变量文档化在 etc/config.mk。make dist 的底层逻辑查看 etc/dist.mk 可以看到dist的真实定义dist: clair-$(VERSION).tar.gz clair-%.tar.gz: vendor/modules.txt tarball$(subst .gz,,$) prefix$(subst .tar.gz,/,$) $(git_archive) --format tar --prefix $$prefix --output $$tarball $* ... tar --append --file $$tarball --transform s,^,$${prefix}, ... vendor gzip -n -q -f $$tarball它与 CI 中release-archiveJob 的做法完全同构git archive打出干净源码树再追加vendor目录最后 gzip 压缩。VERSION的默认值定义在 etc/config.mkVERSION ? $(shell git describe --match v* --long | sed s/\(.\\)-\([0-9]\-g[a-f0-9]\)/\1\2/)即默认从git describe推导形如v4.9.0-3-gabcdef1的版本处理成v4.9.03-gabcdef1也可以通过环境变量VERSION显式覆盖。make dist-container 与容器构建etc/container.mk 定义了容器相关 targetcontainer基于当前工作树构建clair.ocicontainer-build构建并把镜像docker load进本地容器引擎dist-container即clair-$(VERSION).oci它依赖clair-$(VERSION).tar.gz先解包归档再调用 buildctl 构建保证从发布归档构建而非从工作树构建dist-clairctl构建所有上游支持平台的 clairctl 二进制。所有容器构建都经由buildctlBuildKit 客户端完成etc/config.mk中相关的可调变量包括变量默认值说明docker自动探测 podman/docker容器引擎命令buildctl自动探测或go run兜底BuildKit 客户端VERSIONgit describe推导归档/镜像使用的版本IMAGE_NAMElocalhost/clair:latestbuildctl 输出镜像名可用逗号分隔多名称CONTAINER_PLATFORMSamd64 arm64 ppc64le s390x构建的架构OCI 记法OS 恒为 linuxCLAIR_VERSION/GO_VERSION/GOTOOLCHAIN/SOURCE_DATE_EPOCH未设置时跳过透传给 buildctl 的构建参数前三个用于 Dockerfilecontainer.mk还会把--opt platformlinux/arch展开为CONTAINER_PLATFORMS各架构并在GITHUB_ACTIONS环境下启用typegha的构建缓存。Dockerfile 方面Dockerfile 采用多阶段构建build阶段在quay.io/projectquay/golang镜像中交叉编译./cmd/...ctl阶段从 scratch 导出 clairctl最终阶段基于ubi8/ubi-minimal以nobody:nobody用户运行默认ENTRYPOINT [/usr/bin/clair]、EXPOSE 6060、环境变量CLAIR_CONF/config/config.yaml与CLAIR_MODEcombo。实操核对清单一次完整的 Minor 发布把文档与仓库实现串起来一次完整的 minor 发布应包含以下步骤在主线完成本周期功能与修复提交遵循仓库的提交规范可参考 Documentation/contribution/commit_style.md可选手动触发 prepare-release.yml输入分支与目标 Tag合并它生成的 Changelog PR让 CHANGELOG.md 就绪在最新提交上打签名标签并推送分支与标签git tag -as v4.x.0 HEAD git push upstream HEAD:release-4.x tag v4.x.0在 GitHub UI 基于v4.x.0创建 Release正文即 changelog观察 cut-release.yml 自动执行生成clair-v4.x.0.tar.gz、交叉编译全部 clairctl 二进制、推送quay.io/projectquay/clair:4.x.0多架构镜像、部署文档之后的六个月维护期内修复提交先落主线再人工挑选移植到release-4.x分支按 Patch 流程滚动发布。Patch 发布则简化为git checkout release-4.x→git tag -as v4.x.1 HEAD→git push upstream tag v4.x.1→ UI 创建 Release其余全部交给流水线。结语Clair 的发布体系呈现出人工只负责打 Tag 与点按钮、其余全部自动化的设计思路git tag与 UI Release 是唯一的两个人工动作其后源码归档、changelog 生成、跨平台二进制、多架构容器镜像与文档发布均由 cut-release.yml 串联完成而 etc/config.mk、etc/dist.mk、etc/container.mk 与 Makefile 共同保证了 CI 与本地行为的一致性——无论是想参与发布还是只想本地复现一份与线上完全相同的发布归档make dist与make dist-container都是最直接的入口。发布本身的技术门槛很低真正的功夫在于维护期内对 release 分支的持续、规范的 bugfix 回流管理。赞分享网络安全应用安全云原生后端【免费下载链接】clairVulnerability Static Analysis for Containers项目地址https://gitcode.com/gh_mirrors/cl/clair点击查看免费下载相关推荐LobeHub 版本发布工作流Minor/Patch 双轨自动化与 GitHub Release 编写规范LobeHub 版本发布工作流Minor/Patch 双轨自动化与 GitHub Release 编写规范 本文以 LobeHub 仓库内的 version人工智能AI 应用大模型AI Agent多智能体工具调用前端后端Rook 版本发布全流程指南从 Minor Release 分支创建到 Release Artifacts 发布Rook 版本发布全流程指南从 Minor Release 分支创建到 Release Artifacts 发布 本文基于 Rook 仓库 build/rel云原生存储容器编排运维LobeHub Minor Release 工作流实战指南从 canary 分支到 v2.2.0 的自动化发布全流程LobeHub Minor Release 工作流实战指南从 canary 分支到 v2.2.0 的自动化发布全流程 本指南以 LobeHub 仓库中的 Mi人工智能AI 应用大模型AI Agent多智能体工具调用前端后端上一篇【亲测免费】 CMSIS-SVD 解析器项目教程下一篇Boss直聘时间可视化插件3步解决求职信息滞后难题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Clair 发布（Release）流程实战指南：Minor/Patch 版本切割与制品自动化分发
网络安全应用安全云原生后端【免费下载链接】clairVulnerability Static Analysis for Containers项目地址https://gitcode.com/gh_mirrors/cl/clair点击查看免费下载Clair 是面向容器的漏洞静态分析工具其 v4 系列采用约每三个月发布一次新版本、每个版本积极维护六个月的节奏。本文以仓库内 Documentation/contribution/releases.md 为骨架结合.github/workflows下的自动化流水线、Makefile 与 etc 目录下的构建规则完整还原 Clair 从打 Tag、创建发布分支、生成变更日志到自动产出源码归档、跨平台二进制与多架构容器镜像的端到端流程。读完本文你将掌握作为维护者如何亲手切割 Minor/Patch 版本也能理解发布制品的每一环在仓库中由哪段代码或配置驱动。发布节奏与维护策略Clair 的发布策略非常明确发布周期新版本minor release大约每三个月切割一次维护窗口每个发布的版本被积极维护六个月Bugfix 回流修复类提交应先落在master如果适用然后标记为需要 backport 到某个 minor 版本的发布分支release branch。需要指出的是文档明确说明为 release 分支挑选并移植修复提交的过程目前尚未完全形式化原文The process for doing this is not yet formalized这意味着 backport 依赖维护者的判断与人工操作仓库当前没有对应的自动化机制。这一点从仓库现有 GitHub Actions 列表.github/workflows中也能印证其中只有fast-forward.yml、check-fast-forward.yml这类分支管理辅助工作流并不存在自动 backport 的 workflow。版本切割Minor 与 Patch 两条路线Clair 的版本号遵循语义化版本semver习惯v4.x.0表示 minor 版本v4.x.yy0表示 patch 版本。两类版本的操作流程共用同一套工具链区别只在于是否创建新的发布分支。Minor 版本打 Tag 建分支切割一个新的 minor 版本需要同时完成两件事创建带注释的签名 Tag与创建发布分支。文档给出的标准操作如下git tag -as v4.x.0 HEAD git push upstream HEAD:release-4.x tag v4.x.0拆解来看git tag -as会创建一个 annotated-a且带 GPG 签名-s的标签标签消息中应记录版本号与简要说明。使用 annotated 而非 lightweight tag是为了保证标签对象携带作者、日期与消息便于工具链如git describe正确解析版本信息第二条命令同时推送两条 refHEAD:release-4.x把当前提交推送到名为release-4.x的发布分支例如release-4.9tag v4.x.0推送刚创建的标签。推送完成后还需要在 GitHub UI 中基于该 Tag 手动创建一个 Release。这一步不可省略因为后续所有制品发布流程都以此为触发器见下文制品自动化一节。Patch 版本只在发布分支上打 TagPatch 版本与 minor 版本的唯一区别是minor 版本对应的 Tag 只应出现在发布分支上即release-4.x且 patch 发布不需要新建分支。操作序列为git checkout release-4.x git tag -as v4.x.1 HEAD git push upstream tag v4.x.1注意第三步只推送 Tag不再推送分支。随后同样需要在 GitHub UI 基于新 Tag 创建 Release。这里有一个值得强调的约束minor 版本 Tagv4.x.0应当只存在于release-4.x分支上而不是master/main主线上。结合 prepare-release.yml 中release 分支只筛选同 minor 版本的提交生成 changelog的逻辑见下文这种分支组织方式保证了每个 minor 系列的历史变更记录干净、独立。变更日志Changelog的生成Release 之前的准备工作仓库中存在一个手动触发的辅助工作流 .github/workflows/prepare-release.yml它在正式打 Tag 之前为发布准备CHANGELOG.md。该工作流通过workflow_dispatch接收两个输入branch准备发布所基于的分支默认maintag将要发布的 Tag 名称。工作流使用git-chglog工具按指定标签范围生成变更日志核心逻辑是filter_tag--tag-filter-pattern v4 branch输入的分支名 if [[ ${branch%-*} release ]]; then filter_tag--tag-filter-pattern v${branch#release-} fi也就是说如果目标分支是release-4.x形式的发布分支则只筛选该 minor 版本范围内的提交例如v4.9否则在主线只过滤v4前缀的完整历史。生成完毕后工作流通过peter-evans/create-pull-request自动提交一个标题形如tag Changelog Bump的 PR分支名为ready-tag并启用 sign-off。仓库根目录的 CHANGELOG.md 即这一机制的产物其头部记录着如v4.9.0 - 2025-12-08的版本条目并按All、Amqp、Build(Deps)、Chore、Chore(Deps)等类别分组列出提交。制品自动化一条由 GitHub Release 驱动的流水线Clair 的制品发布过程完全自动化由 GitHub 上的 Release 事件驱动。也就是说维护者在 UI 中点击Publish release的那一刻后续的源码归档生成、容器镜像构建与推送会全部自动完成。驱动的核心是 .github/workflows/cut-release.yml。该工作流的触发条件有两类on: push: tags: - v4.* workflow_dispatch: {}推送v4.*形式的 Tag注意分支推送不会触发只有 Tag push 才会手动触发workflow_dispatch用于演练或补发。整个工作流由 7 个 Job 组成形成一条清晰的依赖链config └─→ release-archive ──→ release-binaries ──→ release ──→ publish-container │ 推送 quay 镜像 └─→ publish-binaries上传 clairctl └─→ deploy-documentation1. config集中计算发布元数据第一个 Job 在quay.io/projectquay/golang:1.25容器中运行从GITHUB_REF推导出所有下游需要的变量version即 Tag 本身如v4.9.0tar_prefixclair-tag/用于源码归档内的顶层目录前缀is_prerelease当 Tag 包含alpha、beta或rc时判定为预发布image_tag去掉v前缀后的镜像 Tag如4.9.0image_repo目标仓库上游自动映射为projectquay/clairbuild_go_version/cache_key由容器内go version推导的构建版本与缓存键。这些输出通过needs: [config]被后续所有 Job 消费。2. release-archive构建完整源码归档该 Job 先以fetch-depth: 0完整检出仓库然后执行git fetch origin ${GITHUB_REF}:${GITHUB_REF} # 修复 checkout action 覆盖 tag 的问题 git archive --prefix clair-tag/ -o clair.tar ${GITHUB_REF} go mod vendor tar -rf clair.tar --transform s,^,clair-tag/, vendor gzip clair.tar mv clair.tar.gz clair-tag.tar.gz关键点在于Clair 的源码归档由git archive生成而不是把工作目录直接打包——这保证了归档内容严格等于 Tag 指向的提交状态不包含任何本地未提交的脏文件。由于go mod vendor生成的vendor目录默认不被 git 跟踪Job 会在归档后把 vendor 目录追加进 tar 包并放到对应的clair-tag/前缀下从而让归档成为一个自包含、可离线构建的完整源码包。该 Job 还会调用git-chglog生成 changelog手动触发时生成空文件占位并把clair-tag.tar.gz与changelog作为clair-releaseartifact 上传。3. release-binaries跨平台编译 clairctl在config产出的 Go 构建镜像中该 Job 通过 matrix 组合goarch × goosarm64/amd64/386/ppc64le/s390x×linux/windows/darwin并排除不支持的组合如 darwin-386、windows-ppc64le 等对./cmd/clairctl执行交叉编译go build -trimpath -ldflags-s -w -buildvcsfalse \ -o clairctl-goos-goarch ./cmd/clairctl-trimpath去除构建路径信息-ldflags-s -w剥离符号表与 DWARF-buildvcsfalse禁用 VCS 信息注入注释指出版本信息应由git archive过程负责。产物按clairctl-goos-goarch命名并作为独立 artifact 上传。4. release创建 GitHub Release该 Job 在push事件下执行通过ncipollo/release-action创建 Release标题为version ReleaseRelease 正文bodyFile使用 changelogprerelease标志来自config的is_prerelease输出将clair-*归档附加为 Release 资产。upload_url作为输出暴露给下游供publish-binaries上传二进制使用。5. publish-container构建并推送多架构容器镜像这是制品分发的重头戏。该 Job 依次执行下载clair-releaseartifact 并解包到临时目录作为构建上下文用docker/setup-qemu-action与docker/setup-buildx-action配置多平台构建能力使用docker/login-action凭QUAY_USER/QUAY_TOKEN登录quay.io通过docker/build-push-action一次构建linux/amd64、linux/arm64、linux/ppc64le、linux/s390x四个平台的镜像并推送platforms: linux/amd64,linux/arm64,linux/ppc64le,linux/s390x push: true tags: | quay.io/image_repo:image_tag即最终镜像会被推送到quay.io/projectquay/clair仓库Tag 为去掉v的版本号如4.9.0与文档中container is pushed to the quay.io/projectquay/clair repository的描述一致。当is_prerelease true时额外调用.github/actions/set-image-expiration为预发布镜像设置过期时间QUAY_API_TOKEN避免 alpha/beta/rc 镜像长期滞留。6. publish-binaries 与 deploy-documentationpublish-binaries将上一步 matrix 产出的所有clairctl-*二进制通过upload-release-asset追加上传到刚创建的 Release作为独立的发布资产deploy-documentation在release完成后触发.github/actions/documentation把文档部署上线——这也解释了仓库中 Documentation 目录作为 mdBook见 etc/doc.mk 的booktarget发布的内容如何随版本更新。本地复现制品构建make dist 与 make dist-container除了完全自动化的 CI 路径维护者也可以在本地手工构建发布制品。文档明确给出了两个命令及其配置来源make dist生成完整的源码归档make dist-container基于该归档生成对应的容器镜像控制这些 target 行为的变量文档化在 etc/config.mk。make dist 的底层逻辑查看 etc/dist.mk 可以看到dist的真实定义dist: clair-$(VERSION).tar.gz clair-%.tar.gz: vendor/modules.txt tarball$(subst .gz,,$) prefix$(subst .tar.gz,/,$) $(git_archive) --format tar --prefix $$prefix --output $$tarball $* ... tar --append --file $$tarball --transform s,^,$${prefix}, ... vendor gzip -n -q -f $$tarball它与 CI 中release-archiveJob 的做法完全同构git archive打出干净源码树再追加vendor目录最后 gzip 压缩。VERSION的默认值定义在 etc/config.mkVERSION ? $(shell git describe --match v* --long | sed s/\(.\\)-\([0-9]\-g[a-f0-9]\)/\1\2/)即默认从git describe推导形如v4.9.0-3-gabcdef1的版本处理成v4.9.03-gabcdef1也可以通过环境变量VERSION显式覆盖。make dist-container 与容器构建etc/container.mk 定义了容器相关 targetcontainer基于当前工作树构建clair.ocicontainer-build构建并把镜像docker load进本地容器引擎dist-container即clair-$(VERSION).oci它依赖clair-$(VERSION).tar.gz先解包归档再调用 buildctl 构建保证从发布归档构建而非从工作树构建dist-clairctl构建所有上游支持平台的 clairctl 二进制。所有容器构建都经由buildctlBuildKit 客户端完成etc/config.mk中相关的可调变量包括变量默认值说明docker自动探测 podman/docker容器引擎命令buildctl自动探测或go run兜底BuildKit 客户端VERSIONgit describe推导归档/镜像使用的版本IMAGE_NAMElocalhost/clair:latestbuildctl 输出镜像名可用逗号分隔多名称CONTAINER_PLATFORMSamd64 arm64 ppc64le s390x构建的架构OCI 记法OS 恒为 linuxCLAIR_VERSION/GO_VERSION/GOTOOLCHAIN/SOURCE_DATE_EPOCH未设置时跳过透传给 buildctl 的构建参数前三个用于 Dockerfilecontainer.mk还会把--opt platformlinux/arch展开为CONTAINER_PLATFORMS各架构并在GITHUB_ACTIONS环境下启用typegha的构建缓存。Dockerfile 方面Dockerfile 采用多阶段构建build阶段在quay.io/projectquay/golang镜像中交叉编译./cmd/...ctl阶段从 scratch 导出 clairctl最终阶段基于ubi8/ubi-minimal以nobody:nobody用户运行默认ENTRYPOINT [/usr/bin/clair]、EXPOSE 6060、环境变量CLAIR_CONF/config/config.yaml与CLAIR_MODEcombo。实操核对清单一次完整的 Minor 发布把文档与仓库实现串起来一次完整的 minor 发布应包含以下步骤在主线完成本周期功能与修复提交遵循仓库的提交规范可参考 Documentation/contribution/commit_style.md可选手动触发 prepare-release.yml输入分支与目标 Tag合并它生成的 Changelog PR让 CHANGELOG.md 就绪在最新提交上打签名标签并推送分支与标签git tag -as v4.x.0 HEAD git push upstream HEAD:release-4.x tag v4.x.0在 GitHub UI 基于v4.x.0创建 Release正文即 changelog观察 cut-release.yml 自动执行生成clair-v4.x.0.tar.gz、交叉编译全部 clairctl 二进制、推送quay.io/projectquay/clair:4.x.0多架构镜像、部署文档之后的六个月维护期内修复提交先落主线再人工挑选移植到release-4.x分支按 Patch 流程滚动发布。Patch 发布则简化为git checkout release-4.x→git tag -as v4.x.1 HEAD→git push upstream tag v4.x.1→ UI 创建 Release其余全部交给流水线。结语Clair 的发布体系呈现出人工只负责打 Tag 与点按钮、其余全部自动化的设计思路git tag与 UI Release 是唯一的两个人工动作其后源码归档、changelog 生成、跨平台二进制、多架构容器镜像与文档发布均由 cut-release.yml 串联完成而 etc/config.mk、etc/dist.mk、etc/container.mk 与 Makefile 共同保证了 CI 与本地行为的一致性——无论是想参与发布还是只想本地复现一份与线上完全相同的发布归档make dist与make dist-container都是最直接的入口。发布本身的技术门槛很低真正的功夫在于维护期内对 release 分支的持续、规范的 bugfix 回流管理。赞分享网络安全应用安全云原生后端【免费下载链接】clairVulnerability Static Analysis for Containers项目地址https://gitcode.com/gh_mirrors/cl/clair点击查看免费下载相关推荐LobeHub 版本发布工作流Minor/Patch 双轨自动化与 GitHub Release 编写规范LobeHub 版本发布工作流Minor/Patch 双轨自动化与 GitHub Release 编写规范 本文以 LobeHub 仓库内的 version人工智能AI 应用大模型AI Agent多智能体工具调用前端后端Rook 版本发布全流程指南从 Minor Release 分支创建到 Release Artifacts 发布Rook 版本发布全流程指南从 Minor Release 分支创建到 Release Artifacts 发布 本文基于 Rook 仓库 build/rel云原生存储容器编排运维LobeHub Minor Release 工作流实战指南从 canary 分支到 v2.2.0 的自动化发布全流程LobeHub Minor Release 工作流实战指南从 canary 分支到 v2.2.0 的自动化发布全流程 本指南以 LobeHub 仓库中的 Mi人工智能AI 应用大模型AI Agent多智能体工具调用前端后端上一篇【亲测免费】 CMSIS-SVD 解析器项目教程下一篇Boss直聘时间可视化插件3步解决求职信息滞后难题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考