Selenium Docker 镜像 Chrome 102 版本发布全解析：tag_and_push_browser_images.sh 镜像标签机制深度解读

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

本文基于 docker-selenium 仓库 4.28.1 发布周期 中 Chrome 102.0.5005.115 的标签发布记录，系统讲解 tag_and_push_browser_images.sh 的核心逻辑：如何自动探测容器内浏览器与驱动版本、如何生成 10 个标准化镜像标签，以及这些标签如何在 Selenium Grid 中用于精确定位浏览器、驱动与 Grid 的组合。读完本文，你将掌握这套多标签（multi-tag）发布机制的完整工作流，并能在自己的测试环境中准确解析和选用selenium/node-chrome与selenium/standalone-chrome的任意标签。

一、这篇变更日志记录了什么

在仓库CHANGELOG/archived/4.28.1/目录下，每一个chrome_*.md、edge_*.md、firefox_*.md文件都是一个特定浏览器版本在某一个 Selenium Grid 版本发布时，tag_and_push_browser_images.sh脚本的真实执行输出。chrome_102.md 正是 4.28.1 版本（构建日期 20250202）下 Chrome 102 镜像打标签过程的完整记录。

该记录的核心信息如下：

需要说明的是，这个目录位于CHANGELOG/archived/下，属于归档的版本发布记录：4.28.1 发布于 2025 年 2 月初（构建日期 20250202），当时发布的 Chrome 102 是历史较老的浏览器版本。这类归档日志的意义在于，它完整保留了“某一历史 Grid 版本 × 某一浏览器版本 × 某一驱动版本”的可复现组合信息，供需要锁定旧浏览器版本做兼容性测试的团队查询（详见 CHANGELOG/README.md 中的 Selenium Grid × Browser Version Matrix 矩阵表，4.28.1 行覆盖 Chrome 97～132）。

在开始阅读脚本逻辑之前，先明确命令中 7 个位置参数的含义（对应 tag_and_push_browser_images.sh 的参数解析）：

二、脚本核心流程：探测、短化、生成标签、打标签

tag_and_push_browser_images.sh对chrome分支的处理可以概括为四个步骤。这些步骤的输出全部体现在 chrome_102.md 的日志中。

步骤 1：组装基础版本号

脚本先用版本号与构建日期拼出完整的 Selenium Grid 版本标识：

TAG_VERSION=${VERSION}-${BUILD_DATE}

即4.28.1-20250202，对应日志中的Selenium Grid version -> 4.28.1-20250202。

步骤 2：在容器内探测浏览器与驱动版本

脚本通过docker run --rm临时运行已经构建好的node-chrome镜像，利用容器内自带二进制输出版本号，再经awk提取纯版本字符串（对应 tag_and_push_browser_images.sh）：

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 102.0.5005.115，取第 3 列得到102.0.5005.115；
• chromedriver --version的输出形如ChromeDriver 102.0.5005.61 ...，取第 2 列得到102.0.5005.61。

这正是日志中Chrome version -> 102.0.5005.115与ChromeDriver version -> 102.0.5005.61的来源。这种“从成品镜像反查版本”的设计保证了标签中的版本号与实际打包进镜像的二进制绝对一致，不会出现标签与内容漂移。

步骤 3：由长版本生成短版本

short_version函数以点号分割版本串，只保留主版本和次版本（tag_and_push_browser_images.sh）：

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

于是102.0.5005.115→102.0，102.0.5005.61→102.0，对应日志中的Short Chrome version -> 102.0与Short ChromeDriver version -> 102.0。短版本用于生成更易记忆、更稳定的“主版本级”标签。

步骤 4：生成标签清单并逐一打标签

脚本为node-chrome与standalone-chrome两个镜像生成同一批标签（tag_and_push_browser_images.sh）。在RELEASE_OLD_VERSION=true时，标签数组只包含 6 个“含构建日期”的标签；日志 chrome_102.md 中实际输出的正是这 6 个标签 × 2 个镜像的完整清单。

三、本次发布的 12 个完整镜像标签

下面完整列出 chrome_102.md 中记录的全部打标签结果。同一行中node-chrome与standalone-chrome共用同一标签名，共 6 个标签名、12 条记录。

全版本 + 驱动 + Grid + 构建日期（最精确的组合标签）

selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.28.1-20250202 selenium/standalone-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.28.1-20250202

这一标签唯一定位了“浏览器精确版本 + 驱动精确版本 + Grid 精确版本 + 构建日期”的全部信息，适用于对版本组合有严格要求的 CI 场景。

全版本 + 驱动 + 构建日期（无 Grid 版本）

selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-20250202 selenium/standalone-chrome:102.0.5005.115-chromedriver-102.0.5005.61-20250202

浏览器全版本 + 构建日期（无驱动信息）

selenium/node-chrome:102.0.5005.115-20250202 selenium/standalone-chrome:102.0.5005.115-20250202

短版本 + 短驱动版本 + Grid + 构建日期

selenium/node-chrome:102.0-chromedriver-102.0-grid-4.28.1-20250202 selenium/standalone-chrome:102.0-chromedriver-102.0-grid-4.28.1-20250202

短版本 + 短驱动版本 + 构建日期

selenium/node-chrome:102.0-chromedriver-102.0-20250202 selenium/standalone-chrome:102.0-chromedriver-102.0-20250202

浏览器短版本 + 构建日期

selenium/node-chrome:102.0-20250202 selenium/standalone-chrome:102.0-20250202

四、标签结构与选用建议

结合 docs/docker-hub/node-chrome.md 对标签约定的说明，可以把这套标签体系归纳为三层结构：

1. 基础发布标签：<Major>.<Minor>.<Patch>-<YYYYMMDD>，即4.28.1-20250202，对应每次 Grid 构建的唯一条目；
2. 浏览器维度标签：<BrowserMajor>.<BrowserMinor>（如102.0）与<BrowserMajor>.<BrowserMinor>.<Patch>（如102.0.5005.115），以及它们加上-<YYYYMMDD>的变体；
3. 浏览器 + 驱动 + Grid 全组合标签：<BrowserVersion>-chromedriver-<DriverVersion>[-grid-<GridVersion>][-<YYYYMMDD>]。

实际使用时，可以按需求粒度选择：

• 需要可复现的精确组合（如回归测试定位某个具体缺陷）时，选用最长的102.0.5005.115-chromedriver-102.0.5005.61-grid-4.28.1-20250202；
• 只需要锁定浏览器大版本时，选用selenium/node-chrome:102.0-20250202这类短标签；
• 参考 docs/docker-hub/node-chrome.md 的启动示例，把标签替换为精确版本即可接入 Selenium Grid：

docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.28.1-20250202 docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.28.1-20250202

注意：浏览器镜像启动时务必带上--shm-size=2g，以使用宿主共享内存，避免 Chrome 在容器内因 /dev/shm 过小而崩溃。

五、为什么旧版本发布只打 6 个标签：RELEASE_OLD_VERSION 的作用

细心的读者会发现，chrome_102.md 中每个镜像只有 3 个标签变体（含日期），而没有出现诸如102.0.5005.115-chromedriver-102.0.5005.61、102.0这类不带构建日期的“浮动标签”。原因在于本次执行将第 6 个参数RELEASE_OLD_VERSION设为了true。

查看 tag_and_push_browser_images.sh 的 chrome 分支逻辑：

if [ "${RELEASE_OLD_VERSION}" = "false" ]; then CHROME_TAGS+=( # Browser version and browser driver version ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} # Browser version ${CHROME_VERSION} # Browser version and browser driver version ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} # Browser version ${CHROME_SHORT_VERSION} ) fi

也就是说，只有在新版本发布（RELEASE_OLD_VERSION=false）时才会追加102.0.5005.115、102.0、102.0.5005.115-chromedriver-102.0.5005.61、102.0-chromedriver-102.0这四个浮动标签。这背后的设计意图是合理的：102.0、102.0.5005.115这类不带日期的标签属于“漂移指针”，应始终指向最新一次发布的对应版本；而为历史旧版本补发标签（本次场景）不应覆盖这些浮动标签，以免用户拉取selenium/node-chrome:102.0时得到不符合预期的旧组合。因此旧版本发布只生成带构建日期的、稳定且唯一的标签，既保留了历史组合的可追溯性，又不会破坏新版本标签的语义。

六、标签是怎么“打”上去的：retag 与 Makefile 调用链

retag 函数

打标签动作统一封装在retag()函数中（tag_and_push_browser_images.sh）：

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

其中源镜像固定为node-chrome:4.28.1-20250202（即TAG_VERSION标识的原始构建），目标则是上一步生成的每个标签。PUSH_IMAGE=true时会在打标签后立即推送。本次日志中PUSH_IMAGE=false，因此只生成本地标签，不推送。脚本顶部注释还说明：当PROMOTE_TAGS=true时（发布流程将已测试镜像直接提升为正式镜像），改用docker buildx imagetools create在 registry 之间复制多架构 manifest，避免docker tag只支持本地单架构的限制。

Makefile 中的调用入口

在仓库根目录 Makefile 中，tag_and_push_browser_images目标聚合了所有浏览器的打标签任务，其中 chrome 对应的目标为：

tag_and_push_chrome_images: ./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)

VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、RELEASE_OLD_VERSION均作为 Makefile 变量注入，这也解释了为什么 changelog 记录中的命令能直接对应到同一脚本的同一套参数。该脚本同样支持chromium、edge、firefox、chrome-for-testing等浏览器分支，各分支的标签结构完全一致，仅版本探测命令与驱动命名不同（如 Edge 用microsoft-edge --version与msedgedriver --version，Firefox 用firefox --version与geckodriver --version，详见 tag_and_push_browser_images.sh）。

七、镜像内容从何而来：NodeChrome 构建链路

打标签的对象node-chrome:4.28.1-20250202由 NodeChrome/Dockerfile 构建。该 Dockerfile 以node-base为基础镜像，通过构建参数控制浏览器与驱动的安装：

• ARG CHROME_VERSION="google-chrome-stable"：可指定稳定版、测试版或开发版通道；
• ARG CFT_VERSION="STABLE"与ARG INSTALL_CFT="false"：默认安装常规 Chrome，而非 Chrome for Testing（CFT）；
• ARG CHROME_DRIVER_VERSION：缺省时安装最新发布的 ChromeDriver（调用 install-chromedriver.sh）。

构建时还会把浏览器版本写入容器内的/opt/selenium/browsers/chrome/version文件（NodeChrome/Dockerfile），供 Node 注册 Selenium Grid 时上报能力使用。正是“构建时把浏览器装进镜像 → 发布时从镜像反查版本 → 生成对应标签”这一闭环，保证了 chrome_102.md 中每个标签所声明的版本都真实存在于镜像内。

standalone-chrome则基于node-chrome构建并内置完整 Selenium Grid Server（见 Standalone/Dockerfile 与start-selenium-standalone.sh），因此打标签时两者共用同一版本组合。

八、如何在仓库中查阅更多版本记录

本文分析的是归档目录CHANGELOG/archived/4.28.1/下的记录。仓库的 CHANGELOG/README.md 维护了一张完整的Selenium Grid × 浏览器版本矩阵表：每个 Grid 版本一行，每个浏览器版本一列，单元格的 ✓ 链接到对应的chrome_<ver>.md变更日志。当前最新版本记录位于 CHANGELOG/4.48.0/，其中同样包含chrome_102.md（对应 4.48.0 周期内重新发布的 Chrome 102 组合），归档区则按版本目录（4.28.1～4.47.0）逐层保存历史记录。查询某个浏览器版本在某次 Grid 发布中的具体标签组合，直接打开对应 md 文件即可。

九、小结：一套可复现的镜像版本发布体系

以 chrome_102.md 为窗口，可以看到 docker-selenium 项目镜像发布的核心设计：

1. 版本探测自动化：从成品镜像内执行--version提取真实版本，杜绝标签与内容漂移；
2. 多级标签体系：同一镜像同时拥有全版本、短版本、驱动、Grid、构建日期等不同粒度的标签，兼顾精确锁定与易用记忆；
3. 新旧版本发布隔离：通过RELEASE_OLD_VERSION控制浮动标签的生成，历史版本只保留稳定可追溯的带日期标签；
4. 全浏览器统一机制：同一脚本、同一标签结构覆盖 Chrome/Chromium/Edge/Firefox/CFT，降低维护成本。

对使用者而言，理解这套机制意味着：无论需要“锁定某个具体浏览器+驱动+Grid 组合”用于复现，还是“跟随某个大版本的最新补丁”，都能在 CHANGELOG/README.md 矩阵中找到对应日志，并准确解析出所需镜像标签。

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