Jenkins PR与合并流程：如何关联已构建镜像并支持squash merge

针对你遇到的squash merge导致原镜像标签关联失效、无法复用PR构建镜像的问题，业内常用以下几种落地方案：

1. 基于镜像Digest追踪（最可靠） #

镜像的Digest是镜像内容的唯一哈希值，和标签无关——不管你打多少个标签，只要镜像内容不变，Digest就不会变。

• PR构建阶段：完成镜像打包后，通过docker inspect --format='{{index .RepoDigests 0}}' <your-image>获取镜像的完整Digest（格式类似your-image@sha256:xxxxxx）。
• 把Digest和PR编号、原提交哈希一起存入元数据存储：可以是Jenkins构建的参数/artifacts、内部元数据库，甚至直接写到PR的评论里。
• 合并触发的任务：通过PR编号找到对应的Digest，直接用docker pull <your-image>@<digest>拉取镜像，再打ECR需要的标签（比如main分支的提交哈希、版本号）推送即可。

这种方式完全不依赖Git提交哈希的变化，不管是squash merge还是rebase merge，都能精准复用之前构建的镜像。

2. 用PR源提交哈希标记镜像 #

PR的源分支提交哈希不会因为squash merge而改变，基于这个标识绑定镜像：

• PR构建时，给镜像打双标签：一个是你现在用的pr-<pr-id>-<build-number>，另一个是pr-<pr-id>-<source-commit-sha>（其中<source-commit-sha>是PR源分支的最新提交短哈希）。同时给镜像添加LABEL：LABEL git-source-commit=<full-source-sha>。
• 合并后的任务：通过Git命令找到当前main分支提交对应的PR（比如git log --merges --grep="Merge.*PR #<pr-id>" main），或者调用平台API（GitHub/GitLab API）查询PR详情，拿到源提交哈希，然后去Artifactory查询带有对应标签或LABEL的镜像，直接拉取使用。

3. 共享存储记录PR构建镜像信息 #

搭建一个简单的键值存储（比如Redis、内部数据库），专门记录PR和镜像的关联关系：

• PR构建完成后，以PR编号为Key，把镜像的Digest、标签、构建ID等信息存入存储。
• 合并到main分支时，触发的任务通过PR编号从存储中取出镜像信息，直接拉取对应镜像推送至ECR。
• 可以配合CI系统的Webhook，在PR关闭/合并时自动清理过期数据，避免存储冗余。

这种方式不需要依赖Git的任何提交信息，只靠PR的唯一标识关联，适配所有合并方式。

4. 合并时嵌入镜像Digest到提交信息 #

借助Git平台的merge钩子或自动化Bot，在squash merge时把PR构建的镜像Digest写入新提交的描述中：

• 比如在GitHub上，用Action监听PR的merge事件，当检测到squash merge时，自动从PR的构建记录中取出镜像Digest，追加到新提交的描述里（比如[Mirror Digest] your-image@sha256:xxxxxx）。
• 合并后的Jenkins任务解析main分支最新提交的描述，提取Digest，拉取镜像后推送至ECR。

这种方式不需要额外存储，完全依赖Git提交信息，但需要平台支持自定义merge逻辑。

内容的提问来源于stack exchange，提问作者YoavKlein