企业官网建设流程全解析

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

本文以 CHANGELOG/archived/4.28.1/chrome_118.md 中记录的发布日志为核心，深入解读 Selenium Docker 项目（docker-selenium）如何为一个固定的浏览器版本生成并发布一整套语义化 Docker 镜像标签。读者将掌握tag_and_push_browser_images.sh脚本的参数体系、Chrome 118 与 ChromeDriver 118 的版本检测与短版本推导逻辑、10 个完整标签的命名规则与使用场景，以及这些标签在 Selenium Grid 中的实际拉取方式，从而能够在真实项目中精确锁定镜像版本、规避浏览器升级带来的回归风险。

一、这篇发布日志在说什么

CHANGELOG/archived/4.28.1/chrome_118.md的全文是一段脚本执行记录，对应仓库在发布Selenium Grid 4.28.1（构建日期 20250202）时，为 Chrome 118 浏览器镜像打标签并推送的过程：

./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 -> 118.0.5993.117 Short Chrome version -> 118.0 ChromeDriver version -> 118.0.5993.70 Short ChromeDriver version -> 118.0

这段日志属于 CHANGELOG/README.md 所维护的「Selenium Grid × 浏览器版本矩阵」的一部分。该矩阵用一张大表列出每个 Grid 版本分别提供了哪些浏览器版本的镜像，每个 ✓ 都链接到对应的 changelog 详情页。4.28.1一行覆盖了 Chrome 95～132，而chrome_118.md就是其中 Chrome 118 的详情页。

矩阵的设计动机在 README 中写得很清楚：持续提供最新的 Selenium Grid 核心版本，同时保留用户"锁定浏览器版本"的能力——当某个浏览器版本存在兼容性问题，或团队因内部规范需要固定浏览器时，直接找到对应 tag 拉取镜像即可。需要留意的是，README 也明确提示：项目并未对"每个 Grid 版本 × 每种浏览器版本"的全部组合做完整测试，使用者需要根据自己的测试需求自行评估。

二、命令参数逐个拆解

日志第一行的命令共 7 个位置参数，对应 tag_and_push_browser_images.sh 脚本开头的参数解析：

关于第 6 个参数需要展开说明：脚本中RELEASE_OLD_VERSION="${6:-false}"，而本日志传入true。查看脚本中CHROME_TAGS数组的构造逻辑（tag_and_push_browser_images.sh），当RELEASE_OLD_VERSION=false时会追加 4 个"无日期"标签（如118.0.5993.117-chromedriver-118.0.5993.70、118.0.5993.117、118.0-chromedriver-118.0、118.0）；而true时只生成 6 个带日期或带 grid 版本号的标签。这是因为"旧版本补发"场景下，无日期标签会与最新发布产生歧义——用户在拉selenium/node-chrome:118.0时无法判断它属于哪一批构建，因此补发旧版本时只生成明确带日期/版本的 6 个标签，日志第 9～20 行正是这 6 个标签 × 2 种镜像的完整输出。

从仓库调用链看，该脚本既可以被直接执行，也可以通过 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)

而tag_and_push_browser_images目标则聚合了 chrome、chrome-for-testing、chromium、edge、firefox 五种浏览器的全部打标工作（Makefile）。make传入的$(VERSION)、$(BUILD_DATE)、$(NAMESPACE)、$(PUSH_IMAGE)、$(RELEASE_OLD_VERSION)均来自 Makefile 顶部的变量定义，实际构建流程中由 CI（如 deploy.yml）注入。

三、版本探测与短版本推导

脚本的核心工作之一是从镜像内部探测真实的浏览器与驱动版本。对chrome分支（tag_and_push_browser_images.sh），它用两条docker run命令分别拿到 Chrome 与 ChromeDriver 的版本号：

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.28.1-20250202（发布版本TAG_VERSION=${VERSION}-${BUILD_DATE}）；
• 在容器内执行google-chrome --version与chromedriver --version，再用awk提取对应字段；
• 探测结果即日志第 5、7 行：Chrome118.0.5993.117、ChromeDriver118.0.5993.70。

随后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]}" }

于是得到短版本118.0（日志第 6、8 行）。短版本的价值在于：浏览器主版本升级往往不影响 WebDriver 协议兼容性，118.0这类"主版本号"标签足够满足大多数"我要 Chrome 118 系"的使用场景，同时比精确到 build 号的标签更易读、更稳定。

需要补充的是，这种"从镜像内部探测版本"的做法避免了在构建脚本里硬编码版本号——NodeChrome/Dockerfile中 Chrome 与 ChromeDriver 均可通过构建参数覆盖（CHROME_VERSION、CHROME_DRIVER_VERSION，见 NodeChrome/Dockerfile），实际安装的版本由 install-chrome.sh 与 install-chromedriver.sh 决定，因此以运行时探测结果为准最可靠。ChromeDriver 的安装来源还涉及架构判断：amd64 走 Chrome for Testing 官方源，arm64 等架构则可能回退到 Debian 的chromium-driver包（详见 resolve-chromedriver-source.sh 的注释与分支逻辑）。

四、10 个标签的完整清单与命名规则

日志第 9～20 行共输出10 个不同 tag，它们同时被应用到selenium/node-chrome与selenium/standalone-chrome两个镜像上（tag_and_push_browser_images.sh 中的循环对两个镜像逐一调用retag）。按命名模式可归纳为 4 组：

组 1：完整信息标签（长版本号 + grid 版本）

selenium/node-chrome:118.0.5993.117-chromedriver-118.0.5993.70-grid-4.28.1-20250202 selenium/standalone-chrome:118.0.5993.117-chromedriver-118.0.5993.70-grid-4.28.1-20250202

命名模式：<Chrome完整版本>-chromedriver-<ChromeDriver完整版本>-grid-<Grid版本>-<构建日期>。信息最完整，一次标识出浏览器、驱动、Grid 核心、构建日期四个维度，适合做精确的可追溯部署。

组 2：长版本号 + 构建日期

selenium/node-chrome:118.0.5993.117-chromedriver-118.0.5993.70-20250202 selenium/standalone-chrome:118.0.5993.117-chromedriver-118.0.5993.70-20250202 selenium/node-chrome:118.0.5993.117-20250202 selenium/standalone-chrome:118.0.5993.117-20250202

命名模式：<浏览器版本>[-chromedriver-<驱动版本>]-<构建日期>。其中只带浏览器版本+日期的标签（第 13、14 行）适合不需要关心驱动具体 build 号的场景。

组 3：短版本 + grid 版本

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

命名模式：把浏览器与驱动都换成短版本118.0，保留 grid 版本或构建日期。日志第 15～20 行全部属于这一组，共 6 个。

组 4：无日期标签（本次未生成）

当RELEASE_OLD_VERSION=false（即发布新版本时）还会追加 4 个更短的标签（tag_and_push_browser_images.sh）：

118.0.5993.117-chromedriver-118.0.5993.70 118.0.5993.117 118.0-chromedriver-118.0 118.0

它们是用户最常直接使用的"浮动标签"：selenium/node-chrome:118.0表示"最近一次发布的 Chrome 118 镜像"。但由于本次是为已归档的旧版本（4.28.1）补发标签，RELEASE_OLD_VERSION=true，这 4 个标签被跳过，避免覆盖更新版本已发布的同名单标签。

五、retag 与推送机制

所有标签最终通过retag()函数落到镜像上（tag_and_push_browser_images.sh），其行为分两种模式：

常规模式（本日志所走路径）：

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

• 源镜像始终是selenium/node-chrome:4.28.1-20250202/selenium/standalone-chrome:4.28.1-20250202；
• 先本地docker tag创建别名，日志中的Tagged ...行即这一步骤的输出；
• 本日志PUSH_IMAGE=false，所以只打标不推送（发布阶段通常会再以true执行一次，或将标签同步到 GHCR）。

Promote 模式：当环境变量PROMOTE_TAGS=true时（由 deploy.yml 在发布流程复用已测试镜像而非重建时设置），docker tag无法表达"注册表到注册表"的别名——docker pull只会拉回 runner 自身架构的镜像，导致浏览器标签变成单架构。此时脚本改用docker buildx imagetools create在 manifest 层面直接复制多架构索引，并可通过PROMOTE_GHCR_NAMESPACE在同一调用中同时镜像到 GHCR（tag_and_push_browser_images.sh）。与之配套的还有 Makefile 中的tag_and_push_browser_images_ghcr目标，用于把本地所有标签通过docker buildx imagetools create同步到 GHCR 命名空间。

六、如何用这些标签拉起 Selenium Grid

理解了标签体系后，实际使用非常直接——把node-chrome换成standalone-chrome即可在单容器与 Grid 节点两种形态间切换：

# 单容器模式（Standalone），精确锁定浏览器与驱动版本 docker pull selenium/standalone-chrome:118.0.5993.117-chromedriver-118.0.5993.70-grid-4.28.1-20250202 # 以短版本锁定 Chrome 118 系列（跟随该系列最新补丁） docker pull selenium/node-chrome:118.0-20250202

配合仓库根目录的 docker-compose-v3.yml 使用 Grid 时，只需将image字段指向上述任意 tag，并在测试代码里通过browserName=chrome发起请求。选择建议：

• 追求可复现、可追溯：使用组 1 的完整标签，四个维度一目了然；
• 锁定浏览器大版本、接受补丁更新：使用118.0系短标签；
• 在多个 Grid 版本间对比同一浏览器：在 CHANGELOG/README.md 矩阵中查找对应 Grid 版本下的chrome_118.md，即可拿到该组合的完整标签列表。

需要再次强调：官方矩阵明确指出并未对每个组合做全量测试。对于生产环境，建议在固定标签后先跑一遍自己的冒烟用例（仓库 tests/SeleniumTests 与 tests/SmokeTests 提供了现成参考），再全面放量。

七、延伸：其他浏览器的同类日志

chrome_118.md的格式对所有浏览器一致。tag_and_push_browser_images.sh为每种浏览器准备了独立的 case 分支（tag_and_push_browser_images.sh），差异仅在于版本探测命令与命名前缀：

• chromium：探测chromium --version与chromedriver --version；
• edge：探测microsoft-edge --version与msedgedriver --version，标签前缀用-edgedriver-；
• firefox：探测firefox --version与geckodriver --version，标签前缀用-geckodriver-；
• chrome-for-testing：探测命令相同但awk取字段不同（$5），对应 CfT 版本号格式。

因此，CHANGELOG/archived/4.28.1 下edge_*.md、firefox_*.md等内容与本文结构完全同构，掌握了 Chrome 118 这一例，即可举一反三读懂整个矩阵。

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