企业官网建设流程全解析

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

本篇技术指南以 docker-selenium 仓库中 CHANGELOG/archived/4.30.0/firefox_102.md 这份发布记录为切入点，完整讲解仓库如何为 Firefox 浏览器镜像（node-firefox与standalone-firefox）生成多粒度版本标签并发布到镜像仓库的底层机制。读完本文，你将掌握tag_and_push_browser_images.sh的参数含义、12 类标签的命名规范与适用场景、Firefox/GeckoDriver 版本如何被自动探测，以及这一机制在整个发布链路（构建 → 打标 → 推送 → 记录归档）中的位置。

文档定位：浏览器版本矩阵中的一条可追溯记录

docker-selenium 仓库在 CHANGELOG/README.md 中维护着一张"Selenium Grid × Browser Version"矩阵表，其动机在文档开篇有明确说明：在为 Grid 持续提供最新核心版本的同时，保留用户固定（pin）特定浏览器版本进行测试的能力，包括跨浏览器测试、或在某些浏览器版本存在兼容性问题时锁定旧版本。矩阵中的每个 ✓ 都链接到对应的发布记录文件，firefox_102.md正是 Selenium Grid 4.30.0 这一行、Firefox 102 这一列所指向的详细变更记录。

这份记录不是手工填写的表格，而是真实执行发布脚本后的标准输出归档——它直接证明了仓库"打标签 → 推送 → 记录"这条可审计的发布流水线确实运行过，同时为使用者提供了一份精确到"浏览器版本 × 驱动版本 × Grid 版本 × 构建日期"的镜像清单。

一次真实的标签发布过程：4.30.0 中的 Firefox 102.0.1

firefox_102.md的完整正文如下（该段输出直接来自仓库中的 tag_and_push_browser_images.sh）：

./tag_and_push_browser_images.sh 4.30.0 20250323 selenium false firefox true Tagging images for browser firefox, version 4.30.0, build date 20250323, namespace selenium Selenium Grid version -> 4.30.0-20250323 Firefox version -> 102.0.1 Short Firefox version -> 102.0 GeckoDriver version -> 0.36.0 Short GeckoDriver version -> 0.36 Tagged selenium/node-firefox:102.0.1-geckodriver-0.36.0-grid-4.30.0-20250323 Tagged selenium/standalone-firefox:102.0.1-geckodriver-0.36.0-grid-4.30.0-20250323 Tagged selenium/node-firefox:102.0.1-geckodriver-0.36.0-20250323 Tagged selenium/standalone-firefox:102.0.1-geckodriver-0.36.0-20250323 Tagged selenium/node-firefox:102.0.1-20250323 Tagged selenium/standalone-firefox:102.0.1-20250323 Tagged selenium/node-firefox:102.0-geckodriver-0.36-grid-4.30.0-20250323 Tagged selenium/standalone-firefox:102.0-geckodriver-0.36-grid-4.30.0-20250323 Tagged selenium/node-firefox:102.0-geckodriver-0.36-20250323 Tagged selenium/standalone-firefox:102.0-geckodriver-0.36-20250323 Tagged selenium/node-firefox:102.0-20250323 Tagged selenium/standalone-firefox:102.0-20250323

这段输出透露出几条关键信息：

• 一次执行、两个镜像、六组标签：node-firefox与standalone-firefox各自获得完全相同的 6 个标签，合计 12 行Tagged记录；
• 版本探测是自动完成的：Firefox 版本（102.0.1）、GeckoDriver 版本（0.36.0）都不是手写参数，而是脚本通过docker run进入容器执行firefox --version、geckodriver --version探测出来的；
• 短版本是对称推导的：102.0.1 → 102.0、0.36.0 → 0.36，取主版本号的前两段；
• Grid 版本始终带上构建日期：4.30.0-20250323，保证每次构建的镜像彼此可区分。

脚本全解：tag_and_push_browser_images.sh

发布记录中的每一行输出都能在 tag_and_push_browser_images.sh 中找到对应实现。该脚本是 Makefile 中tag_and_push_firefox_images等目标调用的底层工具，支持chrome、chromium、edge、firefox、chrome-for-testing五种浏览器。

参数表

脚本开头（L1-L9）定义了 7 个位置参数：

其中TAG_VERSION=${VERSION}-${BUILD_DATE}（L15）拼接出 Grid 完整版本，也就是输出第一行的4.30.0-20250323。

Firefox 分支的执行流程

脚本主体是一个case "${BROWSER}"分发（L61-L285），firefox分支位于 L195-L235，核心逻辑分三步：

第一步：探测浏览器与驱动版本

FIREFOX_VERSION=$(docker run --rm ${NAMESPACE}/node-firefox:${TAG_VERSION} firefox --version | awk '{print $3}') GECKODRIVER_VERSION=$(docker run --rm ${NAMESPACE}/node-firefox:${TAG_VERSION} geckodriver --version | awk 'NR==1{print $2}')

脚本以docker run临时启动selenium/node-firefox:4.30.0-20250323，分别执行firefox --version与geckodriver --version，再通过awk抽取版本号。这要求镜像必须先构建成功并存在于本地——这正是发布流程中"先make firefox，后打标签"的依赖顺序的由来。GeckoDriver 的版本抽取使用NR==1只取输出第一行，是因为geckodriver --version的输出包含多行描述文本，版本号位于首行。

第二步：推导短版本

short_version() 函数把完整版本按.切分后只保留前两段：

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

于是102.0.1 → 102.0，0.36.0 → 0.36，与输出完全一致。

第三步：组装标签数组并逐组打标

FIREFOX_TAGS数组（L206-L230）定义了六组基础标签，随后循环对node-firefox与standalone-firefox两个镜像分别执行retag：

for firefox_tag in "${FIREFOX_TAGS[@]}"; do retag node-firefox "${firefox_tag}" retag standalone-firefox "${firefox_tag}" done

retag()（L31-L51）默认执行docker tag，当PUSH_IMAGE=true时追加docker push。脚本同时支持PROMOTE_TAGS=true的"registry-to-registry"发布模式——此时改用docker buildx imagetools create，在不拉取镜像到本地的前提下直接把多架构 manifest 从源仓库指向新标签，确保归档发布的镜像 digest 与测试通过的完全一致。

六组标签的命名规范与适用场景

RELEASE_OLD_VERSION=true的关键作用：当此参数为false（默认）时，脚本还会追加四组不带构建日期的"浮动标签"——102.0.1-geckodriver-0.36.0、102.0.1、102.0-geckodriver-0.36、102.0（L219-L229），用于日常docker pull的便捷引用。而当对已经发布过的旧版本重新打标时（如 4.30.0 归档中的这次操作），脚本刻意跳过这四组标签，避免旧发布覆盖当前最新的浮动标签、造成:102.0指向歧义。这正是文档命令中第 6 个参数为true的语义。

从镜像构建到标签发布的完整链路

firefox_102.md记录的是链条的最后一环，其上游在仓库中环环相扣：

1. 镜像构建：Makefile 中firefox目标（L590-L593）先构建node-firefox，standalone_firefox目标（L614-L617）再从node-firefox派生standalone-firefox；
2. Firefox 与 GeckoDriver 的安装：NodeFirefox/Dockerfile 的 L21-L70 安装指定版本的 Firefox（支持latest、beta-latest、esr-latest及具体数字版本，数字版本走 Mozilla CDN 下载路径），L72-L86 下载对应 GeckoDriver 并以符号链接暴露到/usr/bin/geckodriver。构建期间还会把浏览器名称、版本和 binary 路径写入/opt/selenium/browsers/firefox/（L93-L96），供 Grid 节点注册时上报能力；
3. 版本自检：make firefox_upgrade_version（L765-L770）构建后立即以docker run验证selenium-server.jar info --version、firefox --version、geckodriver --version，与打标脚本的探测命令一脉相承；
4. 打标推送：make tag_and_push_firefox_images（L795-L796）把$(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) firefox $(RELEASE_OLD_VERSION)透传给脚本，即firefox_102.md第一行命令的真实来源；
5. 记录归档：发布记录按CHANGELOG/<Grid版本>/<浏览器>_<主版本>.md存放，旧版本移入archived/目录，由 CHANGELOG/README.md 统一索引。

同一浏览器版本的跨版本演进：4.30.0 与 4.48.0 对比

将归档记录与最新记录对照，可以观察到版本矩阵的演进逻辑：在 CHANGELOG/4.48.0/firefox_102.md 中，同一 Firefox102.0.1镜像在 Selenium Grid 4.48.0 发布中被配上了 GeckoDriver0.37.1（4.30.0 时为 0.36.0）。这说明：

• 浏览器版本矩阵的维护是逐 Grid 版本持续进行的，Firefox 102 这类旧版本仍会随新 Grid 发布重新构建，以便用户在升级 Grid 的同时保留旧浏览器；
• 驱动版本会随发布演进独立升级，因此"浏览器版本相同 ≠ 镜像内容相同"，精确引用应使用包含驱动与 Grid 版本的完整标签。

这也解释了为什么矩阵 README 特意注明：并非每个 Grid 与浏览器版本的组合都经过完整测试（CHANGELOG/README.md 的 Note 段落），使用者需要依据自身测试需求评估选择。

实践：如何选用这些标签

以本记录为例，你可以直接在任意运行 Docker 的机器上拉取对应镜像：

# 精确复现本次发布（浏览器+驱动+Grid+日期） docker pull selenium/node-firefox:102.0.1-geckodriver-0.36.0-grid-4.30.0-20250323 # 日常固定浏览器主版本（若该发布允许浮动标签，通常为最新发布所保留） docker pull selenium/node-firefox:102.0 # 在 Selenium Grid 中作为 Node 运行 docker run -d -p 5555:5555 \ -e SE_EVENT_BUS_PUBLISH_PORT=4442 \ -e SE_EVENT_BUS_SUBSCRIBE_PORT=4443 \ selenium/node-firefox:102.0.1-geckodriver-0.36.0-20250323

选择标签的建议：CI 与生产环境优先使用包含grid-段或至少包含构建日期的标签，保证可复现性；浮动标签（仅浏览器版本号）适合本地开发，但需意识到它指向的 digest 可能随新发布更新。

总结

CHANGELOG/archived/4.30.0/firefox_102.md虽然只是一份简短的发布输出，但它背后是一套完整且可审计的镜像版本治理体系：构建时在 NodeFirefox/Dockerfile 中安装指定版本浏览器与驱动，发布时由 tag_and_push_browser_images.sh 自动探测版本、生成六组标签并同步到 Node 与 Standalone 两种形态，再由 CHANGELOG/README.md 的版本矩阵对外索引。理解这套机制，你就能在 docker-selenium 的镜像海洋中精准定位、复现和锁定任意一次浏览器发布。

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