企业官网建设流程全解析

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

本篇技术指南以 docker-selenium 仓库归档的 4.31.0 发布记录（Chrome 128） 为核心，逐行剖析 Selenium Grid 浏览器镜像发布时的标签生成与推送全流程：从一条发布命令出发，解读其 7 个命令行参数、版本探测与短版本号推导规则、10 个 node-chrome 与 standalone-chrome 标签的命名矩阵，以及 changelog 记录在整个版本管理体系中的角色。读完本文，你将掌握如何读懂任意一条浏览器镜像发布日志、理解 selenium/node-chrome 与 selenium/standalone-chrome 各标签段的含义，并能在自己的发布脚本中复刻这套约定。

一条 changelog 记录承载了什么

该记录本质上是发布流水线的一次真实运行输出，完整保存了 4.31.0 这个 Grid 版本、构建日期 20250414 与 Chrome 128 组合下产生的全部镜像标签。它的信息密度很高，主要包含四类数据：

• 触发命令：./tag_and_push_browser_images.sh 4.31.0 20250414 selenium false chrome true
• 版本快照：Selenium Grid4.31.0-20250414、Chrome128.0.6613.137（短版本128.0）、ChromeDriver128.0.6613.137（短版本128.0）
• 产物清单：为selenium/node-chrome与selenium/standalone-chrome两个镜像各生成 10 个标签
• 历史归档身份：该文件位于 CHANGELOG/archived/4.31.0/，说明 4.31.0 已不再是当前最新版本，已被归档流程移入archived目录

这组数据同时被两个系统消费：面向用户的版本矩阵文档（CHANGELOG/README.md），以及面向发布说明自动化的解析脚本（见后文"changelog 在发布体系中的角色"一节）。

触发命令的 7 个参数

命令./tag_and_push_browser_images.sh 4.31.0 20250414 selenium false chrome true对应脚本 tag_and_push_browser_images.sh 开头的位置参数定义：

在 Makefile 中，这一调用被封装为目标 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 目标则会依次触发 chrome、chrome-for-testing、chromium、firefox、edge 五个浏览器的全量标签流程。

版本号是如何被探测出来的

脚本并非硬编码版本号，而是在运行时从已构建好的镜像里实时读取。对于 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}')

即启动selenium/node-chrome:4.31.0-20250414容器，分别执行google-chrome --version与chromedriver --version，再用awk提取版本字段。这也是记录中Chrome version -> 128.0.6613.137、ChromeDriver version -> 128.0.6613.137两行的来源。

随后short_version()函数把完整版本号截取为"主版本.次版本"：

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

128.0.6613.137按.拆分为数组后取前两段，得到128.0。短版本号的价值在于：它既保留了主版本信息、便于人类快速识别，又不会因 patch 版本频繁变化而生成过多标签，是"稳定的引用点"。

10 个标签的三层命名矩阵

脚本用数组CHROME_TAGS拼出标签，核心格式为：

<ChromeVersion>-chromedriver-<ChromeDriverVersion>-grid-<GridVersion>-<BuildDate>

本例实际生成的 node-chrome / standalone-chrome 标签（两侧一一对应）可分为三组：

第一组：完整版本 + 三级限定（共 6 个）

第二组：RELEASE_OLD_VERSION=false 时追加的 4 个"浮动"标签（本例未生成）

若第 6 个参数为false（即"这不是给旧版本重发"），还会追加不带日期、可在新 patch 版本上持续更新的浮动标签：

• 128.0.6613.137-chromedriver-128.0.6613.137
• 128.0.6613.137
• 128.0-chromedriver-128.0
• 128.0

本例RELEASE_OLD_VERSION=true，因此只生成带日期的 6 个标签。从脚本逻辑看，这组浮动标签用于"当前活跃版本"的稳定引用；当某版本进入归档期后，就通过RELEASE_OLD_VERSION=true关闭它们，避免标签被后续构建意外覆盖。

第三组：retag 的二次分发

对每个标签，脚本调用retag node-chrome "<tag>"与retag standalone-chrome "<tag>"（tag_and_push_browser_images.sh），将同一标签同时应用到 Node 与 Standalone 两种形态。retag()内部执行docker tag，并在PUSH_IMAGE=true时追加docker push；此外还支持PROMOTE_TAGS=true模式——此时源镜像不在本地，改用docker buildx imagetools create在镜像仓库间直接复制 manifest，从而保留多架构索引（参见脚本头部的注释说明）。

标签与镜像形态的对应关系

这套标签约定与官方镜像文档 docs/docker-hub/node-chrome.md 中的 Tagging Convention 完全一致：

selenium/node-chrome-<Major>.<Minor>.<Patch>-<YYYYMMDD> selenium/node-chrome-<browserVersion>-<browserDriver>-<browserDriverVersion>-<Major>.<Minor>.<Patch>-<YYYYMMDD>

文档给出的完整标签示例即本文第一组的全限定形态：<BrowserMajor>.<BrowserMinor>-chromedriver-<DriverMajor>.<DriverMinor>-grid-<Major>.<Minor>.<Patch>-<YYYYMMDD>。这意味着用户可以从标签名反推出镜像内的全部软件版本，例如selenium/node-chrome:128.0-chromedriver-128.0-grid-4.31.0-20250414表示：Chrome 128.0、ChromeDriver 128.0、Selenium Grid 4.31.0、构建于 20250414。

在 Node 形态下，该镜像作为 Selenium Grid 的一个节点使用，运行方式为（详见 docs/docker-hub/node-chrome.md）：

docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:128.0-chromedriver-128.0-grid-4.31.0-20250414

浏览器容器务必使用--shm-size=2g以使用宿主机共享内存。Standalone 形态则把 Grid 与浏览器打包在单容器内，适合快速验证。

changelog 在发布体系中的角色

这类chrome_<版本号>.md文件并非孤立的发布日志，而是被仓库的版本管理体系程序化消费的数据源：

• 版本矩阵：CHANGELOG/README.md 以"Grid 版本 × 浏览器版本"二维矩阵列出每个可用镜像标签，每个 ✓ 链接到对应的 changelog 文件，且最新版本排在最前。该 README 由 CHANGELOG/generate-matrix-readme.py 自动生成——它扫描当前目录与archived目录，按([\w-]+)_(\d+)\.md正则解析文件名，并把旧版本目录移入archived（这正是 4.31.0 位于 archived 的原因）。
• Docker Hub 描述：测试 tests/dockerhub_description/test_resolve_versions.py 验证了解析器resolve_versions.py的行为——它从 changelog 中提取Selenium Grid version行与短版本号，用于生成 Docker Hub 页面上的版本说明；测试用例甚至刻意验证了chrome_128.md这类前缀不会与chrome-for-testing_128.md混淆。
• 归档语义：generate-matrix-readme.py 只保留最新一个版本目录在当前层，其余全部移入archived/，因此归档目录中的记录是"历史发布快照"，其标签在 Registry 中依然存在、可继续拉取，但不再参与矩阵的"最新版本"展示。

适用前提与阅读注意事项

需要明确的是：

1. 本记录是4.31.0 时代（构建日期 20250414）的发布产物。当前仓库最新版本为 4.48.0（如 CHANGELOG/4.48.0/chrome-for-testing_152.md 所示，Chrome 已推进到 152.0），因此 4.31.0 + Chrome 128 属于历史组合，适合作为理解标签约定的范例，而非当前推荐版本。选用镜像时请以 CHANGELOG/README.md 最新矩阵为准。
2. 该记录没有执行docker push（PUSH_IMAGE=false），实际发布由 CI 的 deploy 流程在验证通过后完成。
3. changelog 只记录"该组合下生成了哪些标签"，并不保证每个 Grid × 浏览器组合都被完整测试过——CHANGELOG/README.md 明确说明"并未对每种组合做全量测试，用户需按自己的测试需求评估决策"。

小结

通过chrome_128.md这条记录，可以完整还原 docker-selenium 的浏览器镜像发布链路：先构建node-chrome:<版本>-<日期>基础镜像 → 用docker run实时探测 Chrome/ChromeDriver 版本 →short_version生成短版本 → 拼装 6 或 10 个分层标签 → 通过retag同时应用到 node 与 standalone 两种形态 → 按需docker push→ 将输出沉淀为 changelog 文件供版本矩阵与 Docker Hub 描述消费。这套"版本信息即文件名、标签语义即版本组合"的约定，让用户仅凭镜像标签即可精确定位所需的浏览器、驱动与 Grid 组合，也是 docker-selenium 实现大规模浏览器自动化时的版本可控性根基。

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