企业官网建设流程全解析

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

导读

本文以 CHANGELOG/archived/4.28.1/chrome_106.md 这份归档发布记录为切入点，逐行解读 docker-selenium 项目在发布"指定浏览器版本 + 指定 Selenium Grid 版本"镜像时的多 Tag 命名体系与完整打标流程。读完本文，你将能够：看懂版本矩阵中每个✓对应的镜像 Tag 含义、理解 tag_and_push_browser_images.sh 脚本的七个参数与底层执行逻辑、并在自己的测试环境中精确拉取"Chrome 106 + ChromeDriver 106 + Grid 4.28.1"这一组合的 Node 或 Standalone 镜像。

这份 Changelog 记录是什么：版本矩阵中的一个格子

docker-selenium 项目维护着一张"Grid 版本 × 浏览器版本"的镜像矩阵（见 CHANGELOG/README.md）。该矩阵的动机非常明确：持续供应带新功能的 Selenium Grid 核心版本，同时允许用户在浏览器版本上"钉住"某个旧版本——无论是出于跨浏览器测试覆盖，还是某个浏览器特定版本存在兼容问题需要回退。

矩阵中每一格是一个✓，链接到对应 Grid 版本目录下的浏览器版本 Changelog 文件，例如归档的 4.28.1 版本支持 Chrome 95～132 共 38 个版本，其中chrome_106.md记录的正是Selenium Grid 4.28.1 + Chrome 106.0.5249.119 + ChromeDriver 106.0.5249.61这一组合的镜像打标结果。

需要特别留意矩阵 README 中的一条免责声明：项目并未对"每一种 Grid × 浏览器组合"做全量兼容性测试，用户应根据自己的测试要求自行评估和决策。这意味着这类 Changelog 记录的本质是可用的镜像 Tag 清单，而非兼容性担保。

逐行解读 4.28.1 的 Chrome 106 打标输出

归档记录完整保留了发布命令及其全部输出，我们按三段来解读。

命令行参数拆解

./tag_and_push_browser_images.sh 4.28.1 20250202 selenium false chrome true

对照 tag_and_push_browser_images.sh 开头的参数定义，这条命令的七个位置参数含义如下：

本例第 6 个参数为true，对应"重新发布旧浏览器版本"的场景：此时脚本只生成 6 个带明确语义的 Tag（每个镜像家族），避免把selenium/node-chrome:106.0这类浮动 Tag重新指向旧版本，干扰使用最新版 Chrome 的用户。

版本探测输出

Selenium Grid version -> 4.28.1-20250202 Chrome version -> 106.0.5249.119 Short Chrome version -> 106.0 ChromeDriver version -> 106.0.5249.61 Short ChromeDriver version -> 106.0

这几行是脚本真实执行docker run从镜像内探测出来的结果。对应源码在 tag_and_push_browser_images.sh：

• docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} google-chrome --version | awk '{print $3}'探测 Chrome 完整版本；
• docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} chromedriver --version | awk '{print $2}'探测 ChromeDriver 完整版本；
• short_version函数按.切分后取前两段，生成106.0这样的短版本号（见 short_version）。

12 行 "Tagged" 输出与 Tag 命名规则

记录中一共生成了 12 个 Tag：node-chrome与standalone-chrome两个镜像家族各 6 个。以node-chrome为例：

这些 Tag 集合由 CHROME_TAGS 数组 生成：前 6 个始终生成；只有当RELEASE_OLD_VERSION=false时才会追加 4 个浮动 Tag（${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}、${CHROME_VERSION}、短版本对应的两个），这正是归档记录中看不到selenium/node-chrome:106.0这类 Tag 的原因。standalone-chrome家族完全复用同一组 Tag，仅镜像名不同。

源码视角：打标脚本的完整执行流程

打标与推送：retag函数

每个 Tag 都经由 retag 落地，该函数支持两条路径：

• 常规路径（PROMOTE_TAGS未开启）：执行docker tag "${NAMESPACE}/${image}:${TAG_VERSION}" "${NAMESPACE}/${image}:${tag}"；若PUSH_IMAGE=true，随后执行docker push。
• 镜像晋升路径（PROMOTE_TAGS=true）：当发布流程直接复用 CI 已测试通过的镜像、而不是重新构建时，docker tag无法表达"从远端仓库给 index 加 Tag"且会丢失多架构属性，因此改用docker buildx imagetools create --tag ... ${NAMESPACE}/${image}:${TAG_VERSION}在 registry 之间直接操作镜像 index；若设置了PROMOTE_GHCR_NAMESPACE，同一调用还会同步镜像到 GHCR。

该变量由deploy.yml在发布时注入（见脚本头注释），而tag_and_push_browser_images_ghcr这一 Makefile 目标（Makefile）则是在本地构建路径下，通过docker images枚举全部本地 Tag 并用docker buildx imagetools create镜像到 GHCR 的另一种做法。

分支结构

脚本以case "${BROWSER}"分派到不同的浏览器分支（脚本 L61-L285），每个分支的探测命令与版本号提取列略有差异：

• chrome：google-chrome --version取第 3 列、chromedriver --version取第 2 列，支持--platform；
• chromium：chromium --version取第 2 列；
• edge：microsoft-edge --version取第 3 列、msedgedriver --version取第 4 列；
• firefox：firefox --version取第 3 列、geckodriver --version取第 1 行第 2 列；
• chrome-for-testing：google-chrome --version取第 5 列。

任一分支的 Tag 生成逻辑与 Chrome 完全同构（版本号/日期/短版本三种粒度 × 是否带-grid-前缀），只是把chromedriver替换为对应的geckodriver/edgedriver。

Makefile 集成与发布上下文

打标脚本通过 Makefile 目标接入发布流程（Makefile）：

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)

相关变量默认值也定义在 Makefile 顶部（Makefile）：TAG_VERSION := $(VERSION)-$(BUILD_DATE)、PUSH_IMAGE默认false、RELEASE_OLD_VERSION默认false。也就是说，默认发布会追加浮动 Tag（如selenium/node-chrome:106.0），仅当显式传入RELEASE_OLD_VERSION=true（即归档记录中的场景）时才省略。

发布前的版本一致性核验也可以参考 Makefile 中chrome_upgrade_version目标的写法（Makefile）：构建后依次执行selenium-server.jar info --version、google-chrome --version、chromedriver --version确认三者的版本与预期一致——这与 generate_release_notes.sh 生成发布说明时所用的探测命令完全同源。

实际使用：根据 Tag 精确拉取镜像

理解命名规则后，使用就非常直接。例如需要"Chrome 106 完整版 + ChromeDriver 106 完整版 + Grid 4.28.1-20250202"的 Node 镜像用于 Selenium Grid：

docker pull selenium/node-chrome:106.0.5249.119-chromedriver-106.0.5249.61-grid-4.28.1-20250202

若只关心浏览器主版本而不在意小版本，可以用短版本 Tag：

docker pull selenium/node-chrome:106.0-chromedriver-106.0-grid-4.28.1-20250202

若团队约定以构建日期为准，则使用：

docker pull selenium/standalone-chrome:106.0.5249.119-20250202

也可以参考仓库根目录下的 docker-compose-v3.yml 这类 compose 文件，把image:字段换成上述任意 Tag，即可让整套 Grid（Hub/Node/Standalone）运行在钉死的浏览器版本上。选择 Tag 时建议按此顺序决策：需要精确复现 CI 环境时用"完整版 + grid 版本串"；需要跟上 Grid 修复时用带构建日期的 Tag；不建议在生产测试中依赖无日期浮动 Tag，因为它们会被后续版本重新指向。

归档策略与使用限制

从 CHANGELOG/README.md 可以看到，同一浏览器版本会在多个 Grid 版本下各自保留一份记录：Chrome 106 同时存在于 4.28.1（归档）与 4.48.0（当前）等若干版本目录，Tag 内容结构完全一致，区别仅在 Grid 版本串与构建日期（如 CHANGELOG/4.48.0/chrome_106.md 使用的是4.48.0-20260909）。这种"每版本一份记录"的结构让用户既能横向对比不同 Grid 版本下的同一浏览器，也能纵向回溯某个 Grid 版本支持的全部浏览器范围。

最后再次强调两条使用边界：其一，版本矩阵只保证"镜像已按此组合构建并打标"，不保证所有组合都经过完整功能测试，引入新组合前应在自己的用例上做冒烟验证（仓库的 tests/ 目录提供了 SmokeTests、SeleniumJavaTests 等参考用例）；其二，归档目录下的记录对应已进入维护期的 Grid 版本，除非确有钉版本需求，新项目优先从当前版本目录（如 CHANGELOG/4.48.0）中选择镜像。

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