企业官网建设流程全解析

• 测试
• 后端
• 云原生
• 容器编排
• 可观测性

本文基于 docker-selenium 仓库中 CHANGELOG/archived/4.33.0/chrome_114.md 这份真实发布记录，逐层拆解 Selenium 官方 Docker 镜像的版本标签命名规则、生成脚本与发布流水线，并给出使用者如何利用这套标签精确固定浏览器版本的实战方案。读完本文，你将能读懂仓库中任意一份chrome_xxx.md发布日志，并能根据标签语义精准挑选selenium/node-chrome与selenium/standalone-chrome镜像。

一、这份记录是什么：一次 Chrome 114 镜像发布打标签的全过程

CHANGELOG/archived/4.33.0/chrome_114.md是 Selenium Grid 4.33.0 版本发布时，为 Chrome 114 浏览器镜像执行打标签与推送后留下的完整输出。它忠实记录了tag_and_push_browser_images.sh脚本的一次真实运行结果：

./tag_and_push_browser_images.sh 4.33.0 20250606 selenium false chrome true Tagging images for browser chrome, version 4.33.0, build date 20250606, namespace selenium Selenium Grid version -> 4.33.0-20250606 Chrome version -> 114.0.5735.198 Short Chrome version -> 114.0 ChromeDriver version -> 114.0.5735.90 Short ChromeDriver version -> 114.0 Tagged selenium/node-chrome:114.0.5735.198-chromedriver-114.0.5735.90-grid-4.33.0-20250606 Tagged selenium/standalone-chrome:114.0.5735.198-chromedriver-114.0.5735.90-grid-4.33.0-20250606 Tagged selenium/node-chrome:114.0.5735.198-chromedriver-114.0.5735.90-20250606 Tagged selenium/standalone-chrome:114.0.5735.198-chromedriver-114.0.5735.90-20250606 Tagged selenium/node-chrome:114.0.5735.198-20250606 Tagged selenium/standalone-chrome:114.0.5735.198-20250606 Tagged selenium/node-chrome:114.0-chromedriver-114.0-grid-4.33.0-20250606 Tagged selenium/standalone-chrome:114.0-chromedriver-114.0-grid-4.33.0-20250606 Tagged selenium/node-chrome:114.0-chromedriver-114.0-20250606 Tagged selenium/standalone-chrome:114.0-chromedriver-114.0-20250606 Tagged selenium/node-chrome:114.0-20250606 Tagged selenium/standalone-chrome:114.0-20250606 Tagged selenium/node-chrome:114.0.5735.198-chromedriver-114.0.5735.90 Tagged selenium/standalone-chrome:114.0.5735.198-chromedriver-114.0.5735.90 Tagged selenium/node-chrome:114.0.5735.198 Tagged selenium/standalone-chrome:114.0.5735.198 Tagged selenium/node-chrome:114.0-chromedriver-114.0 Tagged selenium/standalone-chrome:114.0-chromedriver-114.0 Tagged selenium/node-chrome:114.0 Tagged selenium/standalone-chrome:114.0

从输出中可以提取出本次发布的关键事实：

需要注意，这里是 4.33.0 时期的归档记录，属于历史快照；仓库CHANGELOG/目录按版本号归档（CHANGELOG/README.md 中 "Archived Grid Versions" 表格），最新的发布记录位于 CHANGELOG/4.48.0 目录，但标签生成机制自始至终保持一致。

二、标签命名规则逐条拆解：一份标签一个用途

同一份镜像内容（同一批构建产物）会被打上多个语义不同的标签，目的正是让使用者在不同场景下都能"按需取用"。结合tag_and_push_browser_images.sh中CHROME_TAGS数组的生成逻辑，这 10 个标签可以分成两类：

第一类：绑定 Grid 版本与构建日期的"发布专属标签"（6 个）

第二类：不带构建日期的"滚动便捷标签"（4 个）

当RELEASE_OLD_VERSION参数为false时，脚本还会追加 4 个不带构建日期的标签，例如：

• 114.0.5735.198-chromedriver-114.0.5735.90：完整浏览器 + 完整驱动
• 114.0.5735.198：仅完整浏览器版本
• 114.0-chromedriver-114.0：短浏览器 + 短驱动
• 114.0：仅短浏览器版本

这类标签去掉了grid-与日期后缀，是最贴近日常使用的引用方式——例如docker pull selenium/node-chrome:114.0即可拿到当前 114 主版本的镜像。但要注意，这类标签在后续发布中会被新构建覆盖，属于"移动指针"而非不可变快照；追求可复现时应优先使用带构建日期的第一类标签。

node 与 standalone 成对出现

每一组标签都会同时打到两个镜像上：selenium/node-chrome（仅浏览器节点，供 Selenium Grid 集群使用）与selenium/standalone-chrome（浏览器 + Grid 一体化，可独立运行）。这正是 docker-selenium 一贯的镜像分层设计：Node 镜像聚焦于执行测试，Standalone 镜像则把服务端与浏览器打包在一起，便于单机快速验证。

三、脚本如何算出这些版本号：源码级拆解

tag_and_push_browser_images.sh是整个发布链路的关键脚本（仓库根目录），它在运行时接受以下参数：

另有环境变量PROMOTE_TAGS（默认false）与PROMOTE_GHCR_NAMESPACE（默认空）控制镜像提升（promote）模式，详见下一节。

Chrome 分支的版本探测逻辑

脚本并不凭空拼接版本号，而是从刚构建好的镜像内部实际读取浏览器与驱动的版本：

CHROME_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} google-chrome --version | awk '{print $3}') CHROMEDRIVER_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} chromedriver --version | awk '{print $2}')

google-chrome --version的输出形如Google Chrome 114.0.5735.198，awk '{print $3}'取到第三列即版本号；chromedriver --version输出形如ChromeDriver 114.0.5735.90 (...)，awk '{print $2}'取版本号。这一设计保证了标签永远与镜像内真实二进制版本一致，不会出现"标签版本"与"实际版本"错位。

short_version：从完整版本到主版本

function short_version() { local __long_version=$1 local __version_split=(${__long_version//./ }) echo "${__version_split[0]}.${__version_split[1]}" }

该函数以.为分隔符切分版本号，仅保留前两段，从而把114.0.5735.198收敛为114.0。这正是"短版本标签"的来源，让使用者不必记忆冗长的完整版本号。

标签数组的组装

CHROME_TAGS数组按固定模板组装出 6 个基本标签，并在RELEASE_OLD_VERSION=false时追加 4 个便捷标签（即上一节的两类标签），随后循环对node-chrome与standalone-chrome两个镜像逐一调用retag：

for chrome_tag in "${CHROME_TAGS[@]}"; do retag node-chrome "${chrome_tag}" retag standalone-chrome "${chrome_tag}" done

脚本中为不同浏览器（chromium、edge、firefox、chrome-for-testing）提供了同构的case分支，只是版本探测命令与镜像名不同（如 firefox 用firefox --version | awk '{print $3}'与geckodriver --version | awk 'NR==1{print $2}'）。可见这套标签机制是整个仓库所有浏览器镜像的通用发布协议。

四、retag 的三种执行路径：本地打标、推送与 registry 间提升

每次Tagged ...输出都来自retag()函数（tag_and_push_browser_images.sh 第 31-51 行），它根据上下文选择三种执行路径：

路径一：本地打标签（PROMOTE_TAGS=false 的默认路径）

docker tag "${__source}" "${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi

先在本地为源镜像（${TAG_VERSION}格式）追加新标签，PUSH_IMAGE=true时再逐个推送。发布记录中命令的第四个参数是false（selenium false chrome true中的false），说明当时只完成本地打标，推送由流水线后续步骤统一执行。

路径二：registry 间镜像提升（PROMOTE_TAGS=true）

脚本头部注释解释了该模式的背景：当 release 直接发布"已在测试中验证过的镜像"而不是重新构建时（由deploy.yml通过PROMOTE_TAGS触发），本地根本没有源镜像，docker tag无法工作；且docker pull只能拉回运行机架构的单架构镜像，会让多架构标签退化为单架构。此时改用 buildx 的 registry-to-registry 操作：

docker buildx imagetools create --tag "${NAMESPACE}/${__image}:${__tag}" "${__source}"

imagetools create直接操作 manifest index，可以在不落地本地镜像的情况下跨 registry 复制多架构标签。

路径三：同步镜像到 GHCR（PROMOTE_GHCR_NAMESPACE 非空）

若设置了PROMOTE_GHCR_NAMESPACE，同一调用内还会追加一条指向 GHCR 命名空间的--tag，实现"一次调用、双 registry 同步"。脚本注释特别说明：GHCR 镜像同步不能在之后用 Makefile 的tag_and_push_browser_images_ghcr补做，因为该目标依赖docker images发现本地镜像，而提升路径下本地存储是空的。

五、在发布流水线中的位置：Makefile 目标与 GHCR 同步

tag_and_push_browser_images.sh不是孤立脚本，而是通过 Makefile（第 781-808 行）接入完整发布流程：

tag_and_push_browser_images: tag_and_push_chrome_images tag_and_push_chrome-for-testing_images tag_and_push_chromium_images tag_and_push_firefox_images tag_and_push_edge_images tag_and_push_chrome_images: ./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)

• 组合目标tag_and_push_browser_images一次触发五种浏览器的全部打标与推送；
• 各浏览器子目标把VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、RELEASE_OLD_VERSION等 Makefile 变量透传给脚本；
• tag_and_push_browser_images_ghcr目标则遍历本地镜像标签，通过docker buildx imagetools create --tag ${GHCR_NAMESPACE}/... docker.io/${NAMESPACE}/...将 Docker Hub 镜像镜像到 GHCR。

这套 Makefile 封装解释了为什么发布记录中的命令行能直接写成./tag_and_push_browser_images.sh 4.33.0 20250606 selenium false chrome true——它是流水线实际执行的最小单元，参数与 Makefile 变量一一对应。

六、作为使用者：如何利用这套标签固定浏览器版本

理解了标签语义，即可在测试与 CI 中精准选型。以下是按需求场景给出的选标签建议：

# 需要与某个 Grid 版本精确绑定的不可变快照（推荐用于 CI 复现） docker pull selenium/standalone-chrome:114.0.5735.198-chromedriver-114.0.5735.90-grid-4.33.0-20250606 # 只需要固定主版本，接受滚动更新 docker pull selenium/node-chrome:114.0 # 需要固定完整浏览器版本 docker pull selenium/node-chrome:114.0.5735.198 # 需要同时固定浏览器与驱动的完整版本 docker pull selenium/standalone-chrome:114.0.5735.198-chromedriver-114.0.5735.90

查询"哪个 Grid 版本下有哪些浏览器版本可用"，直接查阅 CHANGELOG/README.md 的版本矩阵：每行是一个 Grid 版本，每列是一个浏览器主版本号，交叉单元格的 ✓ 链接指向对应的chrome_xxx.md发布记录（如 4.33.0 行 → archived/4.33.0/chrome_114.md）。README 同时说明：并非所有 Grid × 浏览器组合都经过完整测试，使用者需按自身测试要求评估取舍。

若要理解标签背后的二进制从何而来，可追溯 NodeChrome/Dockerfile：构建阶段通过CHROME_VERSION（默认google-chrome-stable）与CHROME_DRIVER_VERSION两个 ARG 分别控制浏览器与驱动安装，并在构建时把实际版本写入/opt/selenium/browsers/chrome/version——发布脚本读取的正是这份真实产物版本。

七、与其他发布记录的对照：机制的一致性验证

仓库中每个版本目录下都有同构的发布记录，例如最新目录 CHANGELOG/4.48.0/chrome-for-testing_113.md 展示了 Chrome for Testing 113 的发布输出。对照两份记录可以发现：

• 命令结构完全一致（版本 构建日期 命名空间 推送开关 浏览器 旧版本开关），只是浏览器参数从chrome变为chrome-for-testing；
• Chrome for Testing 分支的版本探测使用awk '{print $5}'（因 CFT 的google-chrome --version输出列位置不同），印证了tag_and_push_browser_images.sh中按浏览器定制探测逻辑的设计；
• 标签模板同样遵循"完整版/短版 × 驱动 × Grid × 日期"的组合规则。

这种一致性意味着：只要掌握本文的标签规则与脚本机制，仓库中从 4.28.1 到 4.48.0 的所有浏览器发布记录都可以被快速读懂，并用于镜像选型、版本回退与构建问题排查。

参考文件索引

• 发布记录本体：CHANGELOG/archived/4.33.0/chrome_114.md
• 发布脚本源码：tag_and_push_browser_images.sh
• Makefile 发布目标：Makefile（第 781-808 行）
• 版本矩阵与目录说明：CHANGELOG/README.md
• Chrome 镜像构建参数：NodeChrome/Dockerfile
• 最新发布记录示例：CHANGELOG/4.48.0/chrome-for-testing_113.md

• 测试
• 后端
• 云原生
• 容器编排
• 可观测性