企业官网建设流程全解析

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

本文以 docker-selenium 仓库发布的 Chrome 101 镜像打标签日志为切入点，逐行解读./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true这条命令背后的参数语义、版本探测机制与六类 Tag 的生成规则，并结合 tag_and_push_browser_images.sh、Makefile 与 CHANGELOG/README.md 中的版本矩阵，帮助你彻底理解 Selenium Grid 与浏览器版本组合镜像的发布管线，掌握在真实测试环境中「按标签锁定浏览器 + Driver + Grid 版本组合」的实操能力。

一、日志来源：一次 Chrome 101 镜像的多标签发布

本次发布的完整终端输出如下：

./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true Tagging images for browser chrome, version 4.48.0, build date 20260909, namespace selenium Selenium Grid version -> 4.48.0-20260909 Chrome version -> 101.0.4951.64 Short Chrome version -> 101.0 ChromeDriver version -> 101.0.4951.41 Short ChromeDriver version -> 101.0 Tagged selenium/node-chrome:101.0.4951.64-chromedriver-101.0.4951.41-grid-4.48.0-20260909 Tagged selenium/standalone-chrome:101.0.4951.64-chromedriver-101.0.4951.41-grid-4.48.0-20260909 Tagged selenium/node-chrome:101.0.4951.64-chromedriver-101.0.4951.41-20260909 Tagged selenium/standalone-chrome:101.0.4951.64-chromedriver-101.0.4951.41-20260909 Tagged selenium/node-chrome:101.0.4951.64-20260909 Tagged selenium/standalone-chrome:101.0.4951.64-20260909 Tagged selenium/node-chrome:101.0-chromedriver-101.0-grid-4.48.0-20260909 Tagged selenium/standalone-chrome:101.0-chromedriver-101.0-grid-4.48.0-20260909 Tagged selenium/node-chrome:101.0-chromedriver-101.0-20260909 Tagged selenium/standalone-chrome:101.0-chromedriver-101.0-20260909 Tagged selenium/node-chrome:101.0-20260909 Tagged selenium/standalone-chrome:101.0-20260909

这段日志本质上是一份**「发布记录」**：它展示了在 Selenium Grid4.48.0发布版本中，仓库如何为selenium/node-chrome与selenium/standalone-chrome两种镜像生成一组可追溯、可锁定的 Docker Tag。日志文件保存在 CHANGELOG/4.48.0/chrome_101.md，对应的历史版本归档位于 CHANGELOG/archived/ 各版本目录下（如4.47.0/chrome_101.md），并且所有可用组合都汇总在 CHANGELOG/README.md 的「Grid Version × Browser Version」矩阵中。

二、命令参数拆解：七个位置参数的含义

日志第一行调用的命令是：

./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true

对照 tag_and_push_browser_images.sh 开头的参数解析：

脚本第 15–16 行会据此拼接出构建标签：

TAG_VERSION=${VERSION}-${BUILD_DATE} NAMESPACE=${NAME:-selenium}

即TAG_VERSION=4.48.0-20260909、NAMESPACE=selenium，这解释了日志中出现的所有grid-4.48.0-20260909片段。

脚本第 88 行有一个关键分支：当RELEASE_OLD_VERSION为true时（本次日志即此情况），跳过「仅含浏览器/Driver 版本、不含日期」的短标签（如101.0.4951.64、101.0），只生成带构建日期或 Grid 版本信息的完整标签。这是为了让历史浏览器版本的重发不影响当前主流标签的指向，避免101.0这类短标签与新版 Chrome 镜像产生歧义。当前版本（RELEASE_OLD_VERSION=false）才会追加这些短标签。

三、版本探测：镜像内部的真实版本是如何读出来的

脚本通过docker run临时启动已构建好的镜像，读取内部浏览器与 Driver 的真实版本号，而不是依赖外部参数硬编码：

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}')

对应日志输出：

Chrome version -> 101.0.4951.64 ChromeDriver version -> 101.0.4951.41

随后short_version()函数（脚本第 53–57 行）将长版本截断为主版本.次版本：

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

因此得到101.0.4951.64 → 101.0、101.0.4951.41 → 101.0，对应日志中Short Chrome version -> 101.0与Short ChromeDriver version -> 101.0两行。

这种「从镜像内部探测版本」的设计保证了标签与镜像内容的一致性——标签永远不会与内部实际安装的浏览器/Driver 版本脱节。而 NodeChrome/Dockerfile 也展示了版本信息在构建阶段就被固化到镜像中：镜像内/opt/selenium/browsers/chrome/version文件由google-chrome --version | awk '{print $3}'生成，与脚本探测所用命令一致。这也意味着该日志中的Chrome 101.0.4951.64是一个较旧的历史版本（当前最新已到 152），此日志正是仓库为满足用户「锁定旧浏览器版本」需求而保留的历史发布记录。

四、标签体系：六类 Tag 的完整生成逻辑

脚本第 75–87 行定义了三组「完整标签」和三组「短标签」，每组同时作用于node-chrome与standalone-chrome两个镜像：

CHROME_TAGS=( # 完整版：浏览器版本 + Driver 版本 + Grid 版本 + 构建日期 ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-grid-${TAG_VERSION} # 完整版：浏览器版本 + Driver 版本 + 构建日期 ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-${BUILD_DATE} # 完整版：浏览器版本 + 构建日期 ${CHROME_VERSION}-${BUILD_DATE} # 短版：主次版本 + Driver 主次版本 + Grid 版本 + 构建日期 ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-grid-${TAG_VERSION} # 短版：主次版本 + Driver 主次版本 + 构建日期 ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-${BUILD_DATE} # 短版：主次版本 + 构建日期 ${CHROME_SHORT_VERSION}-${BUILD_DATE} )

代入本次探测到的版本值后，即得到日志中的 12 条Tagged输出。将这 6 类标签按信息粒度整理如下（括号内为该类标签的适用场景）：

日志第 9 行起先输出node-chrome的 6 个标签，再输出standalone-chrome的 6 个标签，正对应脚本第 101–104 行的循环：

for chrome_tag in "${CHROME_TAGS[@]}"; do retag node-chrome "${chrome_tag}" retag standalone-chrome "${chrome_tag}" done

五、retag 函数：标签打制与推送的两条路径

脚本核心的retag()函数（第 31–51 行）根据发布模式走两条不同的路径：

function retag() { local __image=$1 local __tag=$2 local __source="${NAMESPACE}/${__image}:${TAG_VERSION}" if [ "${PROMOTE_TAGS}" = "true" ]; then # 路径一：registry 到 registry 的 manifest 复制（多架构安全） docker buildx imagetools create "${__targets[@]}" "${__source}" ... return fi # 路径二：本地 docker tag + 可选 push docker tag "${__source}" "${NAMESPACE}/${__image}:${__tag}" echo "Tagged ${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi }

• 常规路径（默认）：对本地镜像执行docker tag，为node-chrome:4.48.0-20260909这一基础构建镜像逐一添加别名；当PUSH_IMAGE=true时再逐条docker push。本次日志PUSH_IMAGE=false，因此只打标签、不推送，输出均为Tagged ...而非 push 日志。
• PROMOTE 路径：当PROMOTE_TAGS=true（由部署流程deploy.yml在「复用已测试镜像而非重新构建」时设置，见脚本第 10–13 行注释）时，使用docker buildx imagetools create直接在镜像索引（manifest index）层面、registry 对 registry 地复制标签。这样能保持多架构 manifest的完整性——因为docker tag依赖本地镜像且docker pull只能拉取运行机架构，会导致浏览器标签变成单架构，而imagetools在索引层面操作可以规避这个问题。同时，设置PROMOTE_GHCR_NAMESPACE可在同一次调用中把标签同步镜像到 GHCR 命名空间。

六、发布管线中的位置：Makefile 目标与 CI 集成

这段打标签逻辑并非孤立脚本，而是通过 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)

即一个tag_and_push_browser_images目标会依次为chrome、chrome-for-testing、chromium、edge、firefox五种浏览器执行打标签，参数VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、RELEASE_OLD_VERSION均由 Make 变量注入。

脚本内部也为每种浏览器定义了独立的探测与标签逻辑：

各分支均按照与 Chrome 相同的「完整版三组 + 短版三组」模式生成node-*与standalone-*两套镜像的标签（如node-firefox、standalone-edge、node-chrome-for-testing等）。若传入未识别的浏览器名，脚本会输出Unknown browser!（第 283 行）。

七、使用侧视角：如何用这批标签锁定测试环境

发布这些标签的最终目的是让使用者能够精确锁定浏览器、Driver 与 Grid 的组合。以本次 Chrome 101 为例，可直接使用：

# 最完整的组合锁定（推荐用于跨版本回归） docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:101.0.4951.64-chromedriver-101.0.4951.41-grid-4.48.0-20260909 # 简写标签，便于记忆 docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:101.0-20260909

从 docs/docker-hub/node-chrome.md 的标签约定说明可以看出，这套命名规则与镜像文档中的<browserVersion>-<browserDriver>-<browserDriverVersion>-<Major>.<Minor>.<Patch>-<YYYYMMDD>结构完全对应。使用含grid-前缀的完整标签时，可以确保测试不会因为 Grid 升级而意外改变运行行为；这正是 CHANGELOG/README.md 中「提供最新 Grid 核心能力的同时，允许用户固定浏览器版本」这一设计动机的直接体现。

需要留意的是，CHANGELOG/README.md 明确说明：项目并未对每一种「Grid 版本 × 浏览器版本」组合做全量测试验证，使用者需要根据自己的测试需求评估选择。Chrome 101 属于较早期的浏览器版本，适合用于验证旧版本浏览器兼容性等场景。

八、版本矩阵与历史归档：本日志在仓库中的定位

在 CHANGELOG/README.md 的「Latest Grid Version → Chrome」矩阵中，4.48.0一行从 95 到 152 共 58 个 Chrome 版本均有对应的详细变更记录链接，其中101列的链接即指向本文分析的 CHANGELOG/4.48.0/chrome_101.md。该矩阵同时列出 Chrome for Testing、Edge、Firefox 的对应矩阵，且更早的 Grid 版本（4.28.1 至 4.47.0）的打标签记录归档在 CHANGELOG/archived/ 各版本目录下——例如archived/4.47.0/chrome_101.md记录的是该 Chrome 版本在 4.47.0 Grid 下打标签的完整过程。矩阵中的每个 ✓ 都是指向对应变更记录文档的链接，用于快速定位某一浏览器版本在特定 Grid 版本下的发布细节。

这些归档记录形成了一条完整的时间线：同一浏览器版本在不同 Grid 版本下的标签命名模式保持一致，仅TAG_VERSION（Grid 版本 + 构建日期）不同，这使得使用者可以在升级 Grid 的同时维持浏览器版本不变，或将二者同时升级，均能通过矩阵快速找到对应的镜像标签。

九、小结：一条命令产出的发布资产

以./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true为例，脚本完成的工作可以概括为：

1. 解析 7 个位置参数，确定版本、构建日期、命名空间、推送开关、浏览器类型、历史版本开关与平台；
2. 探测镜像内部真实版本（Chrome 101.0.4951.64 / ChromeDriver 101.0.4951.41），并截取主次版本；
3. 生成 6 类标签，同时作用于node-chrome与standalone-chrome；
4. 通过retag()打制标签，常规模式走docker tag（PUSH_IMAGE=true时附带docker push），发布推广模式走docker buildx imagetools create保持多架构完整性；
5. 输出Tagged ...记录，作为发布证据沉淀到 CHANGELOG/4.48.0/chrome_101.md，并在 CHANGELOG/README.md 矩阵中登记。

理解这一流程后，你在任何需要「固定浏览器版本跑测试」的场景中，都能从仓库的 CHANGELOG 矩阵出发，逆推出应该拉取的镜像标签——这正是 docker-selenium 项目将「最新 Grid + 任意浏览器版本」组合能力交付给使用者的核心机制。

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