测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载本指南以仓库中CHANGELOG/archived/4.32.0/chrome_98.md记录的真实发布日志为主线完整解析 docker-selenium 项目如何通过tag_and_push_browser_images.sh为固定 Chrome 版本 最新 Selenium Grid组合生成并发布 Docker 镜像标签。读完本文你将掌握该脚本的参数含义、版本探测逻辑、标签命名约定、docker tag/docker push的底层实现以及如何在实际测试中正确选择并拉取对应镜像。为什么需要旧浏览器 新 Grid的镜像组合在 docker-selenium 仓库的 CHANGELOG/README.md 中明确说明了这套版本矩阵的设计动机项目希望持续供应最新的 Selenium Grid 核心版本以引入新功能同时让用户能够基于特定浏览器版本进行测试——例如跨浏览器测试或因为某些浏览器版本存在兼容问题而需要锁定旧版本。因此仓库同时交付 Node 与 Standalone 两类镜像将 Grid、浏览器、浏览器驱动打包在一起用户只需找到镜像标签、拉取镜像即可开始测试。CHANGELOG/archived/4.32.0/目录正是这一策略的产物它记录了 Grid 4.32.0 版本对 Chrome 95 至 134 等一批浏览器版本的打包发布过程。其中 chrome_98.md 记录的是一次典型的发布执行日志——对 Chrome 98.0.4758.102 这一早已停止更新的旧版本重新打包进当时最新的 Grid 4.32.0。归档目录本身由 CHANGELOG/generate-matrix-readme.py 维护脚本会按语义化版本排序将除最新版本外的所有 Grid 版本目录移动到archived/下再扫描所有*_version.md文件自动生成 README 版本矩阵表。也就是说这份日志不仅是历史记录更是版本矩阵可追溯性的来源。发布命令与七个位置参数chrome_98.md记录的完整命令如下./tag_and_push_browser_images.sh 4.32.0 20250515 selenium false chrome true对照 tag_and_push_browser_images.sh 顶部的参数解析逻辑该脚本共接受 7 个位置参数位置参数本命令中的值说明$1VERSION4.32.0Selenium Grid 版本号$2BUILD_DATE20250515构建日期YYYYMMDD与 VERSION 拼成TAG_VERSION4.32.0-20250515$3NAMESPACEselenium镜像仓库命名空间即selenium/node-chrome、selenium/standalone-chrome的前缀$4PUSH_IMAGEfalse是否在打标签后执行docker pushfalse表示仅在本机打标签$5BROWSERchrome浏览器类型脚本通过case分支支持chrome、chromium、edge、firefox、chrome-for-testing$6RELEASE_OLD_VERSIONtrue是否以老版本发布模式运行决定是否生成不带构建日期的浮动标签见后文$7PLATFORMlinux/amd64默认值用于探测版本时docker run的--platform参数脚本开始时会输出Tagging images for browser chrome, version 4.32.0, build date 20250515, namespace selenium随后进入chrome)分支。从镜像内部探测真实版本号打标签前脚本必须先确认镜像里实际安装的 Chrome 与 ChromeDriver 版本。这一步通过运行镜像内的可执行文件并用awk抽取版本号实现tag_and_push_browser_images.shCHROME_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 时使用--platform ${PLATFORM}保证在非 amd64 的构建机上也能探测正确架构的镜像--rm使探测容器运行后立即清理awk {print $3}从Google Chrome 98.0.4758.102这类输出中取出版本号因此日志中打印出Chrome version - 98.0.4758.102ChromeDriver 输出形如ChromeDriver 98.0.4758.102 (...)故用awk {print $2}取第二列。随后short_version()函数将完整版本号截短为两位tag_and_push_browser_images.shfunction short_version() { local __long_version$1 local __version_split(${__long_version//./ }) echo ${__version_split[0]}.${__version_split[1]} }它按.拆分后取前两段得到98.0。日志中Short Chrome version - 98.0、Short ChromeDriver version - 98.0即由此而来。短版本标签的价值在于当 Chrome 发布补丁版本如 98.0.4758.103时指向98.0的浮动标签会自动跟着新的补丁版本走适合不想频繁改配置的用户。探测到的版本之所以与安装脚本一致可追溯到镜像构建链NodeChrome/Dockerfile 通过ARG CHROME_VERSION默认google-chrome-stable控制安装的 Chrome并调用install-chrome.shNodeChrome/install-chrome.sh 支持google-chrome-stable具体版本形式从版本归档下载对应.deb精确安装从而保证镜像内版本可被锁定与复现。标签组合规则同一镜像生成 12 个标签日志显示 Chrome 分支在RELEASE_OLD_VERSIONtrue模式下生成了 12 个标签tag_and_push_browser_images.sh可分为三类完整版本 Grid 完整标识形如98.0.4758.102-chromedriver-98.0.4758.102-grid-4.32.0-20250515浏览器、驱动、Grid、构建日期全部精确到点可复现性最强完整版本 构建日期如98.0.4758.102-chromedriver-98.0.4758.102-20250515、98.0.4758.102-20250515省略 Grid 版本但保留日期短版本 构建日期/Grid如98.0-chromedriver-98.0-grid-4.32.0-20250515、98.0-chromedriver-98.0-20250515、98.0-20250515使用两位短版本号。由于RELEASE_OLD_VERSIONtrue脚本跳过第 88-99 行的浏览器版本 浏览器驱动版本不带日期一类浮动标签例如纯98.0.4758.102、纯98.0避免旧版本镜像携带误导性的浮动标签。这与日志输出完全吻合12 个标签全部带20250515或grid-4.32.0-20250515后缀。循环体对node-chrome与standalone-chrome两个镜像名各执行一次retagtag_and_push_browser_images.sh因此日志共出现 24 行Tagged ...。retag 的两种模式docker tag 与 buildx imagetoolsretag()函数tag_and_push_browser_images.sh是打标签的核心实现支持两种模式常规模式PROMOTE_TAGSfalse执行docker tag ${NAMESPACE}/${__image}:${TAG_VERSION} ${NAMESPACE}/${__image}:${__tag}在本地给已构建镜像追加别名若PUSH_IMAGEtrue则再执行docker push。本次日志中PUSH_IMAGEfalse因此只产生Tagged ...输出而不推送。发布提升模式PROMOTE_TAGStrue当 CI 发布时直接推广其测试过的镜像而非重新构建时本地仓库没有对应镜像docker tag无法工作且docker pull只能拉回运行者架构导致单架构标签。此时改用docker buildx imagetools create在镜像索引层registry 到 registry直接创建多架构标签并可通过PROMOTE_GHCR_NAMESPACE在同一调用中同时镜像到 GHCR 命名空间。实战如何根据标签拉取与运行 Chrome 98 镜像结合 docs/docker-hub/node-chrome.md 中的标签约定说明本次发布的核心可用标签为精确锁定selenium/node-chrome:98.0.4758.102-chromedriver-98.0.4758.102-grid-4.32.0-20250515按浏览器主版本锁定selenium/node-chrome:98.0-20250515Standalone 变体同理替换镜像名为selenium/standalone-chrome典型的 Hub Node 运行方式注意浏览器镜像需使用--shm-size2gdocker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:98.0-20250515随后将 WebDriver 测试指向http://localhost:4444即可。该文档同时提醒项目中并未对每一个 Grid × 浏览器组合做完整测试验证CHANGELOG/README.md 中的 Note 也声明了这一点用户在锁定旧浏览器版本时应根据自身测试需求评估该组合的可用性——这也正是固定版本标签存在的意义把选择权交给用户。小结CHANGELOG/archived/4.32.0/chrome_98.md看似只是一段 24 行的命令日志实则是 docker-selenium 版本矩阵发布机制的一个完整切片它串联起参数解析tag_and_push_browser_images.sh、镜像内版本探测、短版本截取、12 类标签组合、retag的双模式实现以及 CHANGELOG/README.md 与 CHANGELOG/generate-matrix-readme.py 组成的矩阵归档体系。对于需要在 Selenium Grid 上固定 Chrome 98 这类旧浏览器版本的测试团队理解这套标签语义即可在版本可复现与标签简洁性之间做出合适的选择。赞分享测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载相关推荐Gutenberg MenuItemsChoice 组件详解在 wordpress/components 中实现菜单单选组Gutenberg MenuItemsChoice 组件详解在 wordpress/components 中实现菜单单选组 本文围绕 Gutenberg 仓测试后端云原生容器编排可观测性docker-selenium 浏览器镜像标签发布全解析以 Selenium Grid 4.32.0 Chrome 113 发布记录为例docker selenium 浏览器镜像标签发布全解析以 Selenium Grid 4.32.0 Chrome 113 发布记录为例 本篇指南以 CH测试后端云原生容器编排可观测性docker-selenium 浏览器镜像多标签发布机制以 Selenium Grid 4.32.0 与 Chrome 105 为例docker selenium 浏览器镜像多标签发布机制以 Selenium Grid 4.32.0 与 Chrome 105 为例 本篇技术指南围绕 doc测试后端云原生容器编排可观测性上一篇RxDB SharedWorker RxStorage 实战指南让多个标签页共享同一个数据库进程下一篇Indico完整会议组织工作流解析征稿、评审、注册一站式服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考