ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Selenium Docker 镜像 Chrome 102 版本发布全解析:tag_and_push_browser_images.sh 镜像标签机制深度解读

Selenium Docker 镜像 Chrome 102 版本发布全解析:tag_and_push_browser_images.sh 镜像标签机制深度解读 测试后端云原生容器编排可观测性【免费下载链接】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 仓库 4.28.1 发布周期 中 Chrome 102.0.5005.115 的标签发布记录系统讲解 tag_and_push_browser_images.sh 的核心逻辑如何自动探测容器内浏览器与驱动版本、如何生成 10 个标准化镜像标签以及这些标签如何在 Selenium Grid 中用于精确定位浏览器、驱动与 Grid 的组合。读完本文你将掌握这套多标签multi-tag发布机制的完整工作流并能在自己的测试环境中准确解析和选用selenium/node-chrome与selenium/standalone-chrome的任意标签。一、这篇变更日志记录了什么在仓库CHANGELOG/archived/4.28.1/目录下每一个chrome_*.md、edge_*.md、firefox_*.md文件都是一个特定浏览器版本在某一个 Selenium Grid 版本发布时tag_and_push_browser_images.sh脚本的真实执行输出。chrome_102.md 正是 4.28.1 版本构建日期 20250202下 Chrome 102 镜像打标签过程的完整记录。该记录的核心信息如下信息项值调用命令./tag_and_push_browser_images.sh 4.28.1 20250202 selenium false chrome trueSelenium Grid 版本4.28.1-20250202Chrome 版本102.0.5005.115短版本102.0ChromeDriver 版本102.0.5005.61短版本102.0镜像命名空间selenium打标签的镜像selenium/node-chrome、selenium/standalone-chrome需要说明的是这个目录位于CHANGELOG/archived/下属于归档的版本发布记录4.28.1 发布于 2025 年 2 月初构建日期 20250202当时发布的 Chrome 102 是历史较老的浏览器版本。这类归档日志的意义在于它完整保留了“某一历史 Grid 版本 × 某一浏览器版本 × 某一驱动版本”的可复现组合信息供需要锁定旧浏览器版本做兼容性测试的团队查询详见 CHANGELOG/README.md 中的 Selenium Grid × Browser Version Matrix 矩阵表4.28.1 行覆盖 Chrome 97132。在开始阅读脚本逻辑之前先明确命令中 7 个位置参数的含义对应 tag_and_push_browser_images.sh 的参数解析位置参数本日志中的值含义1VERSION4.28.1Selenium Grid 版本号2BUILD_DATE20250202构建日期YYYYMMDD3NAMESPACEselenium镜像命名空间Docker Hub 用户名/组织4PUSH_IMAGEfalse是否执行docker pushfalse表示仅本地打标签5BROWSERchrome目标浏览器类型6RELEASE_OLD_VERSIONtrue是否为旧版本发布详见第五节7PLATFORM默认linux/amd64探测版本时运行的平台二、脚本核心流程探测、短化、生成标签、打标签tag_and_push_browser_images.sh对chrome分支的处理可以概括为四个步骤。这些步骤的输出全部体现在 chrome_102.md 的日志中。步骤 1组装基础版本号脚本先用版本号与构建日期拼出完整的 Selenium Grid 版本标识TAG_VERSION${VERSION}-${BUILD_DATE}即4.28.1-20250202对应日志中的Selenium Grid version - 4.28.1-20250202。步骤 2在容器内探测浏览器与驱动版本脚本通过docker run --rm临时运行已经构建好的node-chrome镜像利用容器内自带二进制输出版本号再经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})google-chrome --version的输出形如Google Chrome 102.0.5005.115取第 3 列得到102.0.5005.115chromedriver --version的输出形如ChromeDriver 102.0.5005.61 ...取第 2 列得到102.0.5005.61。这正是日志中Chrome version - 102.0.5005.115与ChromeDriver version - 102.0.5005.61的来源。这种“从成品镜像反查版本”的设计保证了标签中的版本号与实际打包进镜像的二进制绝对一致不会出现标签与内容漂移。步骤 3由长版本生成短版本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]} }于是102.0.5005.115→102.0102.0.5005.61→102.0对应日志中的Short Chrome version - 102.0与Short ChromeDriver version - 102.0。短版本用于生成更易记忆、更稳定的“主版本级”标签。步骤 4生成标签清单并逐一打标签脚本为node-chrome与standalone-chrome两个镜像生成同一批标签tag_and_push_browser_images.sh。在RELEASE_OLD_VERSIONtrue时标签数组只包含 6 个“含构建日期”的标签日志 chrome_102.md 中实际输出的正是这 6 个标签 × 2 个镜像的完整清单。三、本次发布的 12 个完整镜像标签下面完整列出 chrome_102.md 中记录的全部打标签结果。同一行中node-chrome与standalone-chrome共用同一标签名共 6 个标签名、12 条记录。全版本 驱动 Grid 构建日期最精确的组合标签selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.28.1-20250202 selenium/standalone-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.28.1-20250202这一标签唯一定位了“浏览器精确版本 驱动精确版本 Grid 精确版本 构建日期”的全部信息适用于对版本组合有严格要求的 CI 场景。全版本 驱动 构建日期无 Grid 版本selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-20250202 selenium/standalone-chrome:102.0.5005.115-chromedriver-102.0.5005.61-20250202浏览器全版本 构建日期无驱动信息selenium/node-chrome:102.0.5005.115-20250202 selenium/standalone-chrome:102.0.5005.115-20250202短版本 短驱动版本 Grid 构建日期selenium/node-chrome:102.0-chromedriver-102.0-grid-4.28.1-20250202 selenium/standalone-chrome:102.0-chromedriver-102.0-grid-4.28.1-20250202短版本 短驱动版本 构建日期selenium/node-chrome:102.0-chromedriver-102.0-20250202 selenium/standalone-chrome:102.0-chromedriver-102.0-20250202浏览器短版本 构建日期selenium/node-chrome:102.0-20250202 selenium/standalone-chrome:102.0-20250202四、标签结构与选用建议结合 docs/docker-hub/node-chrome.md 对标签约定的说明可以把这套标签体系归纳为三层结构基础发布标签Major.Minor.Patch-YYYYMMDD即4.28.1-20250202对应每次 Grid 构建的唯一条目浏览器维度标签BrowserMajor.BrowserMinor如102.0与BrowserMajor.BrowserMinor.Patch如102.0.5005.115以及它们加上-YYYYMMDD的变体浏览器 驱动 Grid 全组合标签BrowserVersion-chromedriver-DriverVersion[-grid-GridVersion][-YYYYMMDD]。实际使用时可以按需求粒度选择需要可复现的精确组合如回归测试定位某个具体缺陷时选用最长的102.0.5005.115-chromedriver-102.0.5005.61-grid-4.28.1-20250202只需要锁定浏览器大版本时选用selenium/node-chrome:102.0-20250202这类短标签参考 docs/docker-hub/node-chrome.md 的启动示例把标签替换为精确版本即可接入 Selenium Griddocker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.28.1-20250202 docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.28.1-20250202注意浏览器镜像启动时务必带上--shm-size2g以使用宿主共享内存避免 Chrome 在容器内因 /dev/shm 过小而崩溃。五、为什么旧版本发布只打 6 个标签RELEASE_OLD_VERSION 的作用细心的读者会发现chrome_102.md 中每个镜像只有 3 个标签变体含日期而没有出现诸如102.0.5005.115-chromedriver-102.0.5005.61、102.0这类不带构建日期的“浮动标签”。原因在于本次执行将第 6 个参数RELEASE_OLD_VERSION设为了true。查看 tag_and_push_browser_images.sh 的 chrome 分支逻辑if [ ${RELEASE_OLD_VERSION} false ]; then CHROME_TAGS( # Browser version and browser driver version ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} # Browser version ${CHROME_VERSION} # Browser version and browser driver version ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} # Browser version ${CHROME_SHORT_VERSION} ) fi也就是说只有在新版本发布RELEASE_OLD_VERSIONfalse时才会追加102.0.5005.115、102.0、102.0.5005.115-chromedriver-102.0.5005.61、102.0-chromedriver-102.0这四个浮动标签。这背后的设计意图是合理的102.0、102.0.5005.115这类不带日期的标签属于“漂移指针”应始终指向最新一次发布的对应版本而为历史旧版本补发标签本次场景不应覆盖这些浮动标签以免用户拉取selenium/node-chrome:102.0时得到不符合预期的旧组合。因此旧版本发布只生成带构建日期的、稳定且唯一的标签既保留了历史组合的可追溯性又不会破坏新版本标签的语义。六、标签是怎么“打”上去的retag 与 Makefile 调用链retag 函数打标签动作统一封装在retag()函数中tag_and_push_browser_images.shdocker tag ${__source} ${NAMESPACE}/${__image}:${__tag} echo Tagged ${NAMESPACE}/${__image}:${__tag} if [ ${PUSH_IMAGE} true ]; then docker push ${NAMESPACE}/${__image}:${__tag} fi其中源镜像固定为node-chrome:4.28.1-20250202即TAG_VERSION标识的原始构建目标则是上一步生成的每个标签。PUSH_IMAGEtrue时会在打标签后立即推送。本次日志中PUSH_IMAGEfalse因此只生成本地标签不推送。脚本顶部注释还说明当PROMOTE_TAGStrue时发布流程将已测试镜像直接提升为正式镜像改用docker buildx imagetools create在 registry 之间复制多架构 manifest避免docker tag只支持本地单架构的限制。Makefile 中的调用入口在仓库根目录 Makefile 中tag_and_push_browser_images目标聚合了所有浏览器的打标签任务其中 chrome 对应的目标为tag_and_push_chrome_images: ./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、RELEASE_OLD_VERSION均作为 Makefile 变量注入这也解释了为什么 changelog 记录中的命令能直接对应到同一脚本的同一套参数。该脚本同样支持chromium、edge、firefox、chrome-for-testing等浏览器分支各分支的标签结构完全一致仅版本探测命令与驱动命名不同如 Edge 用microsoft-edge --version与msedgedriver --versionFirefox 用firefox --version与geckodriver --version详见 tag_and_push_browser_images.sh。七、镜像内容从何而来NodeChrome 构建链路打标签的对象node-chrome:4.28.1-20250202由 NodeChrome/Dockerfile 构建。该 Dockerfile 以node-base为基础镜像通过构建参数控制浏览器与驱动的安装ARG CHROME_VERSIONgoogle-chrome-stable可指定稳定版、测试版或开发版通道ARG CFT_VERSIONSTABLE与ARG INSTALL_CFTfalse默认安装常规 Chrome而非 Chrome for TestingCFTARG CHROME_DRIVER_VERSION缺省时安装最新发布的 ChromeDriver调用 install-chromedriver.sh。构建时还会把浏览器版本写入容器内的/opt/selenium/browsers/chrome/version文件NodeChrome/Dockerfile供 Node 注册 Selenium Grid 时上报能力使用。正是“构建时把浏览器装进镜像 → 发布时从镜像反查版本 → 生成对应标签”这一闭环保证了 chrome_102.md 中每个标签所声明的版本都真实存在于镜像内。standalone-chrome则基于node-chrome构建并内置完整 Selenium Grid Server见 Standalone/Dockerfile 与start-selenium-standalone.sh因此打标签时两者共用同一版本组合。八、如何在仓库中查阅更多版本记录本文分析的是归档目录CHANGELOG/archived/4.28.1/下的记录。仓库的 CHANGELOG/README.md 维护了一张完整的Selenium Grid × 浏览器版本矩阵表每个 Grid 版本一行每个浏览器版本一列单元格的 ✓ 链接到对应的chrome_ver.md变更日志。当前最新版本记录位于 CHANGELOG/4.48.0/其中同样包含chrome_102.md对应 4.48.0 周期内重新发布的 Chrome 102 组合归档区则按版本目录4.28.14.47.0逐层保存历史记录。查询某个浏览器版本在某次 Grid 发布中的具体标签组合直接打开对应 md 文件即可。九、小结一套可复现的镜像版本发布体系以 chrome_102.md 为窗口可以看到 docker-selenium 项目镜像发布的核心设计版本探测自动化从成品镜像内执行--version提取真实版本杜绝标签与内容漂移多级标签体系同一镜像同时拥有全版本、短版本、驱动、Grid、构建日期等不同粒度的标签兼顾精确锁定与易用记忆新旧版本发布隔离通过RELEASE_OLD_VERSION控制浮动标签的生成历史版本只保留稳定可追溯的带日期标签全浏览器统一机制同一脚本、同一标签结构覆盖 Chrome/Chromium/Edge/Firefox/CFT降低维护成本。对使用者而言理解这套机制意味着无论需要“锁定某个具体浏览器驱动Grid 组合”用于复现还是“跟随某个大版本的最新补丁”都能在 CHANGELOG/README.md 矩阵中找到对应日志并准确解析出所需镜像标签。赞分享测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载相关推荐Selenium Grid Docker 镜像版本标签发布全解析以 Chrome 104 为例解读 tag_and_push_browser_images.shSelenium Grid Docker 镜像版本标签发布全解析以 Chrome 104 为例解读 tag_and_push_browser_images.s测试后端云原生容器编排可观测性docker-selenium 4.48.0 版本 Chrome 145 镜像标签生成全解析从 tag_and_push_browser_images.sh 看版本矩阵与镜像标签体系docker selenium 4.48.0 版本 Chrome 145 镜像标签生成全解析从 tag_and_push_browser_images.sh测试后端云原生容器编排可观测性docker-selenium 4.48.0 发布日志解读Chrome 116 镜像的多维标签体系与 tag_and_push_browser_images.sh 打标签机制docker selenium 4.48.0 发布日志解读Chrome 116 镜像的多维标签体系与 tag_and_push_browser_images.测试后端云原生容器编排可观测性上一篇React Hot Loader与 Zustand状态管理库热更新兼容方案下一篇终极指南Dio HTTP/2连接管理的高性能优化策略创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表