ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

docker-selenium Chrome 125 镜像标签全解析:从发布日志到 Tagging 约定的实战指南

docker-selenium Chrome 125 镜像标签全解析:从发布日志到 Tagging 约定的实战指南 测试后端云原生容器编排可观测性【免费下载链接】docker-seleniumProvides 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/archived/4.30.0/chrome_125.md 展开完整解读 Selenium Grid 4.30.0 构建构建日期 20250323配套 Chrome 125.0.6422.141 时生成的全部镜像标签并结合仓库中的打标脚本、Chrome/ChromeDriver 安装逻辑与官方标签约定文档说明每个标签的含义、生成过程与使用场景。读完本文你将能够读懂 docker-selenium 浏览器镜像的任意标签并能在自己的 Grid 中精确选择、固定或发布对应的node-chrome与standalone-chrome镜像版本。这份发布日志记录了什么事在 docker-selenium 的版本管理体系中CHANGELOG目录维护了一张Grid 版本 × 浏览器版本矩阵表见 CHANGELOG/README.md其中每一项都对应一份独立的发布记录文件。以archived/4.30.0/chrome_125.md为例它归档的是Selenium Grid 4.30.0构建标签4.30.0-20250323与 Chrome 125 的组合Selenium Grid 版本4.30.0-20250323Chrome 版本125.0.6422.141短版本125.0ChromeDriver 版本125.0.6422.141短版本125.0该文件以代码块形式保存了一次tag_and_push_browser_images.sh的真实执行输出逐行列出了为node-chrome和standalone-chrome两个镜像生成的20 个标签。发布日志虽短却是理解整个浏览器镜像打标体系的最佳入口——它把版本→标签的映射关系完整呈现了出来。完整复现4.30.0 下 Chrome 125 的标签输出原发布日志的核心内容如下保留全部输出行./tag_and_push_browser_images.sh 4.30.0 20250323 selenium false chrome true Tagging images for browser chrome, version 4.30.0, build date 20250323, namespace selenium Selenium Grid version - 4.30.0-20250323 Chrome version - 125.0.6422.141 Short Chrome version - 125.0 ChromeDriver version - 125.0.6422.141 Short ChromeDriver version - 125.0 Tagged selenium/node-chrome:125.0.6422.141-chromedriver-125.0.6422.141-grid-4.30.0-20250323 Tagged selenium/standalone-chrome:125.0.6422.141-chromedriver-125.0.6422.141-grid-4.30.0-20250323 Tagged selenium/node-chrome:125.0.6422.141-chromedriver-125.0.6422.141-20250323 Tagged selenium/standalone-chrome:125.0.6422.141-chromedriver-125.0.6422.141-20250323 Tagged selenium/node-chrome:125.0.6422.141-20250323 Tagged selenium/standalone-chrome:125.0.6422.141-20250323 Tagged selenium/node-chrome:125.0-chromedriver-125.0-grid-4.30.0-20250323 Tagged selenium/standalone-chrome:125.0-chromedriver-125.0-grid-4.30.0-20250323 Tagged selenium/node-chrome:125.0-chromedriver-125.0-20250323 Tagged selenium/standalone-chrome:125.0-chromedriver-125.0-20250323 Tagged selenium/node-chrome:125.0-20250323 Tagged selenium/standalone-chrome:125.0-20250323注意一个细节日志中命令的第四个参数是false、第六个参数是true。对照脚本参数顺序见下节这意味着PUSH_IMAGEfalse仅本地打标、不推送且RELEASE_OLD_VERSIONtrue旧版本发布模式——因此输出中只出现了 12 个标签另外 8 个面向新版本发布的标签不带构建日期的纯浏览器/驱动版本标签未在本条命令中生成。这是理解为什么发布日志里只有这些标签的关键。打标脚本逐参数解读这份日志的第一行就是脚本的调用方式./tag_and_push_browser_images.sh 4.30.0 20250323 selenium false chrome true对照 tag_and_push_browser_images.sh 第 1-9 行的参数声明各位置含义如下位置参数本日志取值含义1VERSION4.30.0Selenium Grid 主版本号2BUILD_DATE20250323构建日期YYYYMMDD与VERSION拼接为TAG_VERSION4.30.0-202503233NAMESPACEselenium镜像命名空间最终镜像为selenium/node-chrome等4PUSH_IMAGEfalse是否执行docker pushfalse表示仅本地打标5BROWSERchrome目标浏览器脚本内通过case分支支持chrome、chromium、edge、firefox、chrome-for-testing6RELEASE_OLD_VERSIONtrue是否为旧版本补打标签true时不生成不带日期的版本标签7PLATFORM省略探测浏览器版本时使用的平台默认linux/amd64脚本内部还有两个由环境变量控制、日志中未出现的开关PROMOTE_TAGS与PROMOTE_GHCR_NAMESPACE。当PROMOTE_TAGStrue时retag()函数不再使用本地docker tag而是用docker buildx imagetools create在 registry 之间直接复制 manifest以保证多架构标签不被破坏见脚本第 31-51 行的retag()实现。标签是如何生成的版本探测与命名规则从镜像内探测真实版本打标前脚本需要知道镜像里实际装的 Chrome 与 ChromeDriver 版本。以chrome分支为例脚本第 63-73 行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})即临时运行node-chrome:4.30.0-20250323容器分别执行google-chrome --version与chromedriver --version再用awk提取版本字段。由于 Chrome 125 属于稳定版非 Chrome for Testing 分支输出为Google Chrome 125.0.6422.141取第 3 个字段即得到125.0.6422.141。这也解释了发布日志开头的四行版本输出。短版本号short_version函数short_version()脚本第 53-57 行取主版本与次版本function short_version() { local __long_version$1 local __version_split(${__long_version//./ }) echo ${__version_split[0]}.${__version_split[1]} }因此125.0.6422.141→125.0ChromeDriver 同理。短版本标签便于快速锁定大版本线如只要是 125.x 都可以长版本标签则精确到具体构建。标签集合六类 × 新旧版本模式脚本第 75-99 行定义了 Chrome 的标签数组。始终生成的 6 类标签每个又分别打到node-chrome与standalone-chrome共 12 个标签形态示例适用场景完整版本三件套带 Grid 版本125.0.6422.141-chromedriver-125.0.6422.141-grid-4.30.0-20250323精确复现测试环境完整版本 构建日期125.0.6422.141-chromedriver-125.0.6422.141-20250323固定浏览器驱动组合浏览器版本 构建日期125.0.6422.141-20250323以浏览器为主维度短版本三件套带 Grid 版本125.0-chromedriver-125.0-grid-4.30.0-20250323锁定大版本线并绑定 Grid短版本 构建日期125.0-chromedriver-125.0-20250323锁定大版本线短浏览器版本 构建日期125.0-20250323最简短的稳定引用仅当RELEASE_OLD_VERSIONfalse新版本发布时追加的 4 类标签各 2 个镜像共 8 个标签形态示例完整版本 驱动版本125.0.6422.141-chromedriver-125.0.6422.141纯完整版本125.0.6422.141短版本 短驱动版本125.0-chromedriver-125.0纯短版本125.0这正是发布日志只输出 12 个标签的原因RELEASE_OLD_VERSIONtrue意味着这是一次针对已归档旧版本的补打标操作刻意跳过了会与当前活跃版本产生歧义的裸版本标签。打标与推送retag()的实际动作对于普通路径PROMOTE_TAGSfalseretag()执行docker tag ${NAMESPACE}/${__image}:${TAG_VERSION} ${NAMESPACE}/${__image}:${__tag} # 若 PUSH_IMAGEtrue 则追加 docker push ${NAMESPACE}/${__image}:${__tag}node-chrome与standalone-chrome通过循环脚本第 101-104 行对同一个标签集合分别打标for chrome_tag in ${CHROME_TAGS[]}; do retag node-chrome ${chrome_tag} retag standalone-chrome ${chrome_tag} done所以日志中每个标签成对出现Node 一份、Standalone 一份。由于本次PUSH_IMAGEfalse日志只有Tagged而没有推送步骤在正式发布流程中会通过make tag_and_push_chrome_images见 Makefile 第 783-784 行传入$(PUSH_IMAGE)触发实际的docker push。标签约定的官方文档依据docs/docker-hub/node-chrome.md 中给出了与脚本一一对应的标签结构说明selenium/node-chrome-Major.Minor.Patch-YYYYMMDD selenium/node-chrome-browserVersion-browserDriver-browserDriverVersion-Major.Minor.Patch-YYYYMMDD官方文档同时指出Major.Minor.Patch指的是Selenium Grid Server版本browserVersion/browserDriver则指向浏览器与驱动。将文档中的通用模板代入本发布日志可得如下完整映射以短版本 完整 Grid 标签为例e126989f151e selenium/node-chrome 125.0 e126989f151e selenium/node-chrome 125.0-20250323 e126989f151e selenium/node-chrome 125.0-chromedriver-125.0-20250323 e126989f151e selenium/node-chrome 125.0-chromedriver-125.0-grid-4.30.0-20250323文档建议在生产环境中使用完整标签固定浏览器与 Grid 版本而不是latest因为latest会随每次发布漂移导致测试环境与线上不一致。如何实际使用这些标签以日志中的selenium/node-chrome:125.0-chromedriver-125.0-20250323为例一个标准的 Hub Node 部署方式参考 docs/docker-hub/node-chrome.md 的How to run this image# 1. 创建网络 docker network create grid # 2. 启动 Hub docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.30.0-20250323 # 3. 启动 Node务必带上 --shm-size docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:125.0-chromedriver-125.0-20250323要点--shm-size2g不可省略浏览器镜像依赖宿主机共享内存否则 Chrome 容易因/dev/shm过小而崩溃README 的 Troubleshooting 一节亦单独强调此点。Node 通过SE_EVENT_BUS_HOSTselenium-hub加入 Grid测试代码只需指向http://localhost:4444。若想单容器跑Standalone 模式直接使用日志中的selenium/standalone-chrome:125.0-20250323它内置了 Grid Server 与 Chrome。如需可视化调试可访问http://localhost:7900/?autoconnect1resizescalepasswordsecretnoVNC。用完后清理docker network rm grid。Chrome 125 时代的 ChromeDriver 来源源码侧印证Chrome 125即 125.0.6422.141是Chrome for TestingCfT时代的版本Chrome 115 起 Google 全面启用 CfT 发布体系。这一点在镜像构建脚本中有明确的版本判断逻辑NodeChrome/install-chromedriver.sh 第 44-47 行if [ ${ARCH} amd64 ] [ -n ${CHROME_MAJOR_VERSION} ] [ ${CHROME_MAJOR_VERSION} -lt 115 ]; then DRIVER_SOURCElegacy ...由于 125 ≥ 115ChromeDriver 的下载路径不再走chromedriver.storage.googleapis.com的旧 API而是由 NodeChrome/resolve-chromedriver-source.sh 解析为 Chrome for Testing 官方源https://storage.googleapis.com/chrome-for-testing-public/版本/linux64/chromedriver-linux64.zip这也从侧面解释了为什么发布日志中 Chrome 与 ChromeDriver 版本号完全一致125.0.6422.141CfT 体系中驱动与浏览器按同一版本号锁步发布。与此同时NodeChrome/Dockerfile 第 65-72 行会把google-chrome --version的探测结果写入/opt/selenium/browsers/chrome/version供 Grid Node 上报浏览器能力发布日志中打标脚本探测到的版本正是这一构建时信息在运行时的复现。从发布日志到版本矩阵归档与查阅这份chrome_125.md位于CHANGELOG/archived/4.30.0/下属于已归档的旧版本记录当前活跃版本记录位于 CHANGELOG/4.48.0/chrome_125.md内容结构与归档版完全一致同一 Chrome 125.0.6422.141但 Grid 版本为4.48.0-20260909。这意味着Chrome 125 镜像在多个 Grid 版本中持续供应——从 4.28.1 到 4.48.0 的 Chrome 矩阵中均有chrome_125.md条目见 CHANGELOG/README.md 的 Archived Grid Versions 表格。这种一个浏览器版本、多个 Grid 版本的矩阵设计正是 CHANGELOG/README.md 所述的项目动机在持续跟进最新 Selenium Grid 核心功能的同时允许用户为兼容性、稳定性等原因固定某个浏览器版本。查阅方式也简单直接在矩阵表中找到目标 Grid 版本行与浏览器版本列点击对应的 ✓ 链接即可进入该组合的发布日志从中挑选最适合的镜像标签。小结一份仅 21 行的发布日志实际承载了整个 docker-selenium 浏览器镜像标签体系的精华参数即流程VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、BROWSER、RELEASE_OLD_VERSION六个参数决定了打标行为的全部变体版本探测即事实来源标签中的版本号不是猜测而是来自docker run容器内google-chrome --version/chromedriver --version的真实输出标签分层从完整版本 驱动 Grid三件套到短版本 日期覆盖精确复现、大版本锁定、快速引用三类需求源码可印证ChromeDriver 的 CfT 下载路径、Node Dockerfile 的版本写入逻辑、Makefile 的发布入口都与日志输出一一对应。当你在 docker-selenium 的版本矩阵中看到125.0-chromedriver-125.0-grid-4.30.0-20250323这样的标签时现在你已经能准确说出它的每一个组成部分以及它是如何被生成和发布的。赞分享测试后端云原生容器编排可观测性【免费下载链接】docker-seleniumProvides 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 Chrome 125 镜像标签全解析从 tag_and_push_browser_images 脚本看 4.48.0 版本发布实战docker selenium Chrome 125 镜像标签全解析从 tag_and_push_browser_images 脚本看 4.48.0 版本发布测试后端云原生容器编排可观测性docker-selenium 镜像标签发布全解析从 tag_and_push_browser_images.sh 看 Chrome 98 与 Selenium Grid 4.28.1 的标签约定docker selenium 镜像标签发布全解析从 tag_and_push_browser_images.sh 看 Chrome 98 与 Seleniu测试后端云原生容器编排可观测性Selenium Docker 镜像发布实战从 Chrome 130 发布日志解读镜像标签体系与打标签流程Selenium Docker 镜像发布实战从 Chrome 130 发布日志解读镜像标签体系与打标签流程 说明这是一篇基于当前仓库 CHANGELOG/a测试后端云原生容器编排可观测性上一篇SoundSwitch.Common 共享层开发指南通用原语、图标基础设施与变更规则下一篇BlockNote 表格列复制到纯文本tableCol.md 快照与 CellSelection 剪贴板序列化解析创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表