news 2026/10/4 11:21:10

docker-selenium 浏览器镜像 Tag 命名规范与发布流程：以 Chrome 117.0.5938.149 为例

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
docker-selenium 浏览器镜像 Tag 命名规范与发布流程：以 Chrome 117.0.5938.149 为例
  • 测试
  • 后端
  • 云原生
  • 容器编排
  • 可观测性

【免费下载链接】docker-selenium

Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Container Platform, making it easier to perform browser automation at scale

项目地址：https://gitcode.com/GitHub_Trending/do/docker-selenium
点击查看免费下载

本篇指南以 docker-selenium 仓库 CHANGELOG 归档目录中的一份真实发布记录（Selenium Grid 4.28.1 × Chrome 117 镜像打标输出）为线索，结合仓库根目录的 tag_and_push_browser_images.sh 脚本源码与 Makefile 中的相关目标，系统讲解浏览器镜像版本标签（Tag）体系的生成原理与命名规范。读完本文，你将理解selenium/node-chrome与selenium/standalone-chrome各标签的构成含义，掌握如何按需固定浏览器版本、如何读懂发布打标日志，以及如何在 Docker Compose 与 Selenium Grid 测试中正确引用这些镜像标签。

一次真实的 Chrome 117 发布打标记录

在 CHANGELOG/archived/4.28.1/chrome_117.md 中，完整记录了一次针对 Chrome 117 镜像的发布打标过程。其内容是一段由tag_and_push_browser_images.sh脚本产生的真实执行日志：

./tag_and_push_browser_images.sh 4.28.1 20250202 selenium false chrome true Tagging images for browser chrome, version 4.28.1, build date 20250202, namespace selenium Selenium Grid version -> 4.28.1-20250202 Chrome version -> 117.0.5938.149 Short Chrome version -> 117.0 ChromeDriver version -> 117.0.5938.149 Short ChromeDriver version -> 117.0 Tagged selenium/node-chrome:117.0.5938.149-chromedriver-117.0.5938.149-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:117.0.5938.149-chromedriver-117.0.5938.149-grid-4.28.1-20250202 Tagged selenium/node-chrome:117.0.5938.149-chromedriver-117.0.5938.149-20250202 Tagged selenium/standalone-chrome:117.0.5938.149-chromedriver-117.0.5938.149-20250202 Tagged selenium/node-chrome:117.0.5938.149-20250202 Tagged selenium/standalone-chrome:117.0.5938.149-20250202 Tagged selenium/node-chrome:117.0-chromedriver-117.0-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:117.0-chromedriver-117.0-grid-4.28.1-20250202 Tagged selenium/node-chrome:117.0-chromedriver-117.0-20250202 Tagged selenium/standalone-chrome:117.0-chromedriver-117.0-20250202 Tagged selenium/node-chrome:117.0-20250202 Tagged selenium/standalone-chrome:117.0-20250202

逐段解读这段日志，可以还原出整个发布流程的关键信息：

  • 命令语义：脚本接收 7 个位置参数。4.28.1是 Selenium Grid 版本（VERSION），20250202是构建日期（BUILD_DATE），selenium是镜像命名空间（NAMESPACE），false表示本次仅打标、不推送（PUSH_IMAGE），chrome是目标浏览器（BROWSER），末尾的true是 RELEASE_OLD_VERSION 标记。
  • Grid 版本标识：Selenium Grid version -> 4.28.1-20250202，即脚本内部组合出的TAG_VERSION，格式为VERSION-BUILD_DATE。
  • 浏览器与驱动版本：Chrome version -> 117.0.5938.149、ChromeDriver version -> 117.0.5938.149。在这份记录中，Chrome 与 ChromeDriver 的版本号完全一致；二者随后被各自截取前两段得到短版本117.0。
  • 打标结果：共输出 12 行Tagged，即node-chrome与standalone-chrome两个镜像、各 6 个标签。因为命令中 RELEASE_OLD_VERSION 为true，脚本跳过了 4 个不带构建日期的"裸版本"标签（详见下文）。

需要说明的是，这份记录属于 Selenium Grid 4.28.1 的归档发布。仓库 CHANGELOG/README.md 中的版本矩阵显示，最新 Grid 版本（如 4.48.0）的 chrome_117.md 记录了完全相同的打标结构与输出格式，说明这套标签命名规则从 4.28.1 一直沿用至今，对当前版本依然有效。

打标脚本与命令行参数说明

产生上述日志的脚本位于仓库根目录的 tag_and_push_browser_images.sh，它负责为已构建好的浏览器镜像批量打上多种语义的标签。脚本共接收 7 个位置参数：

参数脚本变量含义本记录中的值默认值
$1VERSIONSelenium Grid 版本号4.28.1无
$2BUILD_DATE镜像构建日期（YYYYMMDD）20250202无
$3NAMESPACE镜像命名空间seleniumselenium
$4PUSH_IMAGE是否在打标后执行docker pushfalsefalse
$5BROWSER目标浏览器类型chrome无
$6RELEASE_OLD_VERSION是否为旧版本打标truefalse
$7PLATFORM目标平台未传linux/amd64

其中PUSH_IMAGE、RELEASE_OLD_VERSION、PLATFORM在脚本中均带默认值，可从 tag_and_push_browser_images.sh 的参数声明行看到。NAMESPACE变量还有一个细节：脚本第 16 行使用NAME环境变量作为兜底（NAMESPACE=${NAME:-selenium}），因此也可以通过设置NAME环境变量覆盖命名空间。

在正常发布流程中，该脚本通常不是被手动直接调用的，而是经由 Makefile 中的tag_and_push_chrome_images目标间接执行：

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

Makefile 还提供了同模式的tag_and_push_chrome-for-testing_images、tag_and_push_chromium_images、tag_and_push_edge_images、tag_and_push_firefox_images目标，对应脚本内case "${BROWSER}"分派的五个浏览器分支（chrome、chromium、edge、firefox、chrome-for-testing），每个分支的标签命名逻辑彼此对称。

六类核心标签的命名规范

以 chrome 分支为例（见 tag_and_push_browser_images.sh），脚本会基于四个版本变量拼接标签：

  • ${CHROME_VERSION}：完整 Chrome 版本，如117.0.5938.149
  • ${CHROMEDRIVER_VERSION}：完整 ChromeDriver 版本
  • ${CHROME_SHORT_VERSION}/${CHROMEDRIVER_SHORT_VERSION}：取前两段的主次版本，如117.0
  • ${TAG_VERSION}：VERSION-BUILD_DATE，如4.28.1-20250202
  • ${BUILD_DATE}：构建日期，如20250202

无论 RELEASE_OLD_VERSION 取值如何，脚本总会生成以下 6 类标签（依次对应记录中每行Tagged输出）：

标签格式本记录中的实际示例语义
${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-grid-${TAG_VERSION}117.0.5938.149-chromedriver-117.0.5938.149-grid-4.28.1-20250202完整锁定浏览器、驱动与 Grid 三者的精确版本
${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-${BUILD_DATE}117.0.5938.149-chromedriver-117.0.5938.149-20250202锁定完整浏览器与驱动版本，附构建日期
${CHROME_VERSION}-${BUILD_DATE}117.0.5938.149-20250202锁定完整浏览器版本，附构建日期
${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-grid-${TAG_VERSION}117.0-chromedriver-117.0-grid-4.28.1-20250202主次版本级别的浏览器、驱动与 Grid 组合
${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-${BUILD_DATE}117.0-chromedriver-117.0-20250202主次版本级别的浏览器与驱动组合，附构建日期
${CHROME_SHORT_VERSION}-${BUILD_DATE}117.0-20250202主次版本级别的浏览器版本，附构建日期

此外，当RELEASE_OLD_VERSION为默认值false时（即发布"当前"版本），脚本还会追加 4 个不带构建日期的标签：${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}、${CHROME_VERSION}、${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}、${CHROME_SHORT_VERSION}。这类"裸版本"标签用于给用户提供一个稳定、简短、可长期引用的标识。

而本记录中 RELEASE_OLD_VERSION 为true，脚本据此跳过了这 4 个标签，只保留带日期或 grid 信息的 6 个标签——从代码逻辑看（tag_and_push_browser_images.sh），这是为了避免给历史版本打上无日期标签后，用户误以为该标签指向当前发布流。

版本探测与打标底层实现

这份日志中出现的版本号并非脚本硬编码，而是脚本在运行时从镜像内部实际探测出来的，整个过程位于 chrome 分支的 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}')

脚本通过docker run临时启动已经构建好的node-chrome:4.28.1-20250202镜像，分别在容器内执行google-chrome --version与chromedriver --version，再用awk截取版本号字段。这保证了标签永远与镜像内实际安装的二进制版本一致，而不是依赖构建参数中的声明。镜像内 Chrome 的安装与版本落盘由 NodeChrome/Dockerfile 的ARG CHROME_VERSION="google-chrome-stable"及 NodeChrome/Dockerfile 中写入/opt/selenium/browsers/chrome/version的逻辑负责，脚本侧只是消费其真实结果。

短版本由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]}" }

它按.切分完整版本号并只输出前两段，因此117.0.5938.149→117.0。

最终的每个标签都经由retag()函数落地（tag_and_push_browser_images.sh），其行为分三种路径：

  • 常规路径：docker tag在本地为镜像附加标签；若PUSH_IMAGE=true，随后执行docker push；
  • 发布推广路径（PROMOTE_TAGS=true）：不经过本地镜像存储，而是用docker buildx imagetools create直接在 registry 的 manifest index 层面为已发布镜像补标签，从而完整保留多架构 manifest；
  • 当设置了PROMOTE_GHCR_NAMESPACE时，retag会在同一调用中同时把标签镜像到 GHCR。

从源码结构看，PROMOTE_TAGS机制是当前 CI 发布流程（先测试后推广发布）的一部分，与 Makefile 中promote_release_images等目标的"registry 到 registry 复制、不重建镜像"思路一致。

在 Selenium Grid 测试中如何选用这些标签

上述标签的直接消费方是测试编排。最典型的方式是把镜像标签写进 Docker Compose 的image字段，例如仓库中的 docker-compose-v2.yml：

services: chrome: image: selenium/node-chrome:4.48.0-20260905 ...

由此可以将本文的标签体系对应到实际使用场景：

  • 固定浏览器版本做兼容性回归：当被测站点只在 Chrome 117 上表现稳定、或团队正在跟踪 117 系列的行为差异时，可直接docker pull selenium/node-chrome:117.0.5938.149-20250202（或 standalone 版本），把浏览器钉死在117.0.5938.149这一精确补丁版本上，避免上游 Chrome 自动升级引入不稳定因素。
  • 锁定浏览器与 Grid 双版本：...-grid-4.28.1-20250202这类标签同时锁定了 Grid 组件与浏览器/驱动版本，适合需要可复现的整套 Grid 环境时使用；这是 6 类标签中信息最完整、精度最高的一种。
  • 按主次版本粗略跟随补丁更新：117.0-20250202或裸版本117.0只约束大版本与次版本，拉取时若仓库后续推送了同主次版本的新补丁镜像，标签会指向新镜像，适合希望"跟随 117 系列、不关心补丁号"的自动化环境。
  • 跨浏览器矩阵测试：node（Node 形态）与 standalone（Standalone 形态）两类镜像的标签完全成对出现（记录中每行都是 node-chrome 与 standalone-chrome 相邻），前者用于注册进 Grid 的分布式部署，后者用于单容器独立运行；配合 CHANGELOG/README.md 的版本矩阵，可以快速找到"某个 Grid 版本 × 某个浏览器版本"是否发布过对应镜像。

需要提醒的是，CHANGELOG/README.md 明确指出：项目并未对"每一种 Grid 与浏览器版本的组合"做完整的功能回归测试，因此当组合较新或较特殊时，建议用户先在自己团队的用例上做冒烟验证，再决定是否大规模接入。

归档记录在版本矩阵中的定位

CHANGELOG/README.md 以"Grid 版本 × 浏览器版本"矩阵的形式，把每个 changelog 文档组织为交叉点上的一个链接：行是 Grid 版本（最新版在上，历史版本进入 Archived 区），列是浏览器大版本（Chrome、Chrome for Testing、Edge、Firefox 各自成表）。本文所依据的 chrome_117.md 正是 4.28.1 行的 Chrome 117 列对应的发布记录。

对于正在维护旧版本测试环境的团队，这种归档策略的价值在于：即使当前 Grid 版本早已迭代，依然可以通过归档目录查到历史版本对应浏览器镜像的精确标签，从而在旧基础设施上还原出与当时发布完全一致的可复现环境；而当前版本的同名记录（如 4.48.0/chrome_117.md）则说明，只要该浏览器版本仍在发布矩阵中，相同的标签命名规则会持续生效，迁移到新 Grid 版本时无需学习新的标签语法。

综上，docker-selenium 的浏览器镜像标签体系可以概括为一句话：以"浏览器版本 × 驱动版本 × Grid 版本 × 构建日期"为维度自动组合出多级精度的标签，同时向 node 与 standalone 两类镜像成对发布。理解了这套规范，无论是读发布日志、选固定版本，还是写自己的镜像发布脚本，都能做到心中有数。

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

【免费下载链接】docker-selenium

Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Container Platform, making it easier to perform browser automation at scale

项目地址：https://gitcode.com/GitHub_Trending/do/docker-selenium
点击查看免费下载

相关推荐

上一篇：如何用Files文件管理器5分钟搞定GitHub仓库管理
下一篇：从Horst3180到Arc-Design：Arc Theme的发展历程与未来展望

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/10/4 11:18:38

AI-For-Beginners 符号人工智能实战：知识表示与专家系统构建指南

教程人工智能机器学习深度学习 【免费下载链接】AI-For-Beginners 12 Weeks, 24 Lessons, AI for All! 项目地址： https://gitcode.com/GitHub_Trending/ai/AI-For-Beginners 点击查看 免费下载 本指南对应 AI-For-Beginners 课程的第 2 课"知识表示与专家系统…

作者头像 李华
网站建设 2026/10/4 11:18:20

MCP协议：让AI编程助手真正融入IDE的通信总线

1. 项目概述：当AI编程助手不再只是“代码补全”，而是真正坐进你的IDE里写需求、改Bug、跑测试“基于 MCP 协议构建商业级 AI 编程智能体的技术实践与落地指南”——这个标题里藏着一个正在发生的范式转移。过去三年，我带团队在金融、SaaS和嵌…

作者头像 李华
网站建设 2026/10/4 11:18:11

基于MKV44与MR25H40CDF的工业数据存储方案：选型、驱动与掉电保护

工业现场做控制器，最怕的不是逻辑跑飞，而是数据写到一半、断电抢断，重启之后一切变“新”。我这几年的项目里，电机驱动、UPS、光伏逆变器都在用 MKV44F64VLH16 这类主控，真正让人头皮发麻的往往是数据存储这一层&#…

作者头像 李华
网站建设 2026/10/4 11:18:06

GitHub日榜项目高效筛选与评估：十分钟构建技术雷达

1. 日榜项目的真实价值：为什么值得每天花十分钟扫一遍很多人对GitHub热榜有个误解，觉得那不过是"今天star涨得快的仓库列表"，扫一眼标题就划走了。我刚开始也这么想，直到有段时间连续跟踪了两周日榜，才发现这…

作者头像 李华
网站建设 2026/10/4 11:18:03

基于MR25H40CDF与TM4C129的工业嵌入式数据存储完整方案

工业嵌入式系统的数据存储和数据读取，在很长一段时间里被我当作最没有技术含量的部分。直到做产线数据采集终端时，接连遇到掉电丢最后一条日志、Flash 反复擦写后数据错乱、现场维护人员抱怨记录读不出来等状况，我才真正把注意力放到存储介质…

作者头像 李华
网站建设 2026/10/4 11:17:24

插件加载失败怎么办？插件机制与通用排查方法一次讲透

最近后台收到不少朋友发来的截图，清一色都是各类插件报错：有嵌入式开发里 IAR 弹出来的插件加载异常，有 MusicFree 里加完插件源却搜不到歌的，也有前端工程在 Web Boot 阶段直接刷出一屏 "Failed to load plugins" 的启…

作者头像 李华