dependabot-core Docker 生态解析Docker 镜像标签的 Semver、日期与构建号更新机制【免费下载链接】dependabot-core Dependabots core logic for creating update PRs.项目地址: https://gitcode.com/GitHub_Trending/de/dependabot-coredependabot-core 的docker生态负责扫描仓库中的 Dockerfile、Kubernetes/Helm YAML 清单识别其中的基础镜像并自动创建版本更新 PR。本文以 docker 生态 README 为核心逐条拆解其支持的镜像标签tag模式——Semver、日期、构建号——并深入到 Tag 类实现 与 UpdateChecker 更新管线说明一个镜像是如何从注册表上的一个 tag变成可执行的更新候选的。dependabot-docker 生态的目录布局与独立打包docker/README.md 开头给出了两个关键信息该目录是dependabot-core中 Docker 生态的支持代码docker_compose生态虽然独立打包但代码与测试分别放在docker/lib/dependabot/docker_compose/和docker/spec/dependabot/docker_compose/下以便共享公共代码的同时保持独立的包管理。从源码结构看这一说明与目录完全对应docker/lib/dependabot/docker/Docker 生态核心组件包括file_fetcher.rb、file_parser.rb、file_updater.rb、metadata_finder.rb、update_checker.rb、tag.rb、version.rb、requirement.rb、package_manager.rbdocker/lib/dependabot/docker_compose/compose 文件解析、抓取与更新组件docker/lib/dependabot/shared/两个生态共享的抓取、解析、更新与凭证发现逻辑shared_file_fetcher.rb、shared_file_parser.rb、shared_file_updater.rb、utils/credentials_finder.rb。打包层面docker目录同时包含 dependabot-docker.gemspec 与 dependabot-docker_compose.gemspec 两个 gemspec印证了 README 中共享代码、独立包管理的设计。本地运行开发环境与测试README 给出了完整的本地运行步骤依赖仓库根目录的docker-dev-shell开发环境脚本启动 Docker 生态开发 shellbin/docker-dev-shell docker进入目录后运行测试[dependabot-core-dev] ~ $ cd docker rspecCI 场景下docker/script/ci-test 是各生态通用的测试入口docker/Dockerfile 则用于构建该生态的运行时镜像。测试资产同样围绕标签场景组织docker/spec下包括tag_spec.rb直接覆盖Tag类的same_but_less_precise?、looks_like_prerelease?、dated_version?、comparable_to?、numeric_version等判断update_checker_spec.rb使用docker/spec/fixtures/docker/registry_tags/下的模拟 tag 列表如openjdk.json、fulldate_in_tag.json、multiple-intermediate-words.json验证候选筛选file_parser_spec.rb、file_updater_spec.rb覆盖docker/spec/fixtures/docker/dockerfiles/中 20 多个 Dockerfile 样例digest、digest_and_tag、multi_stage_different_tags、v1_tag等以及docker/spec/fixtures/kubernetes/、docker/spec/fixtures/helm/下的清单文件。支持的标签模式Supported tag schemasREADME 的Supported tag schemas一节是核心Dependabot 支持更新使用 Semver 版本号、日期、构建号这三类 Docker 标签。实现位于 Tag 类README 原文指出的位置即docker/lib/dependabot/docker/tag.rb。Semver前缀与后缀必须同时匹配README 的规则是Dependabot 会尝试从 tag 中解析 Semver并且只会更新到前缀和后缀都匹配的 tag。以 README 的原文示例为例base-12.5.1被解析为prefix-version形式base-12.5.1-golden被解析为prefix-version-suffix因此对base-12.5.1而言只有同样是prefix-version的 tag 才是可行更新对base-12.5.1-golden而言只有prefix-version-suffix的 tag 可行唯一例外当后缀是 SHA 时不做后缀比较只比较prefix-version部分。对应到 tag.rb 的源码标签分解由一组正则完成见 tag.rb#L13-L23WORDS_WITH_BUILD /(?:(?:-[a-z])-[0-9])/ VERSION_REGEX /v?(?version[0-9](?:[_.][0-9])*(?:\.[a-z0-9]|#{WORDS_WITH_BUILD}|-(?:kb)?[0-9])*)/i VERSION_WITH_SFX /^(?operator[~^]*)#{VERSION_REGEX}(?suffix-[a-z][a-z0-9.\-]*)?$/i VERSION_WITH_PFX /^(?prefix[a-z][a-z0-9.\-_]*-)?#{VERSION_REGEX}$/i VERSION_WITH_PFX_AND_SFX /^(?prefix[a-z\-_]-)?#{VERSION_REGEX}(?suffix-[a-z\-])?$/iTag#prefix、Tag#suffix、Tag#version三个访问器直接从NAME_WITH_VERSION的命名捕获组中取值。可比性判断在 Tag#comparable_to? 中要求prefix、format、suffix三者分别相等或满足跨格式可比规则见下文日期与构建号一节。SHA 后缀的例外由format :sha_suffixed分支实现——当另一标签是 SHA 后缀时只比较equal_prefix equal_format不比较后缀见 tag.rb#L98-L101。是否更新的最终比较用的是numeric_version见 tag.rb#L177-L190把版本号中的连字符后缀字母段剥掉、转小写再交给 Version 类 排序。Version用DOCKER_VERSION_REGEX先切出前缀再按_拆出 Java 风格的更新号如11.0.16_8中的8比较键是[release_part, update_part]二元组这一细节在 version_spec.rb 中有直接验证11.0.16_8 11.0.16.1、17.0.2_8 17.0.1_12。日期yyyy-mm 与 yyyy-mm-ddREADME 说明Dependabot 能解析yyyy-mm、yyyy-mm-dd两种日期格式分隔符也可以写成.并更新到最新日期。原文示例2024-01会更新到2024-022024.01.29会更新到2024.03.15。源码中Tag#format通过两个特征正则识别日期格式见 tag.rb#L156-L175return :year_month if version.match?(/^[12]\d{3}(?:[.\-]|$)/) return :year_month_day if version.match?(/^12(?:[.\-]|$)/)即版本号以[12]xxx年份 1xxx/2xxx开头、后跟-或.或结束时判为:year_month或:year_month_day。这正是2024-014 位年份 月与2024.01.29年份 月 日两类样例的来源fulldate_in_tag场景在 update_checker_spec.rb 中有专门的 fixturefulldate_in_tag.json覆盖。一个容易被忽略但很关键的设计在 Tag#comparable_formatsyear_month与year_month_day之间是互相可比的2024-01与2024-01-15同属日期族build_num与日期格式之间同样互相可比。前提是所有参与比较的 tag 都没有前缀、没有后缀。这让月粒度 tag 升到日粒度 tag或构建号 tag 升到日期 tag成为可能而不是各自为政。构建号version-ea-build_num模板匹配README 的第三类Dependabot 识别构建号build number并更新到可用列表中的最高构建号。原文示例21-ea-32→version-ea-build_num22-ea-7→version-ea-build_num22-ea-jdk-nanoserver-1809→version-ea-jdk-nanoserver-build_num因此对21-ea-32而言只有22-ea-7是可行更新候选——它是唯一遵守version-ea-build_num这个精确模板的 tag22-ea-jdk-nanoserver-1809的模板多了jdk-nanoserver一段格式不匹配。这个模板化逻辑由 tag.rb 中WORDS_WITH_BUILD正则/(?:(?:-[a-z])-[0-9])/见 tag.rb#L13驱动凡是若干-[小写词]后跟-[数字]的尾部结构都会被format方法转写成version…-build_num形式的模板字符串见 tag.rb#L163-L172该处源码注释与 README 示例逐字一致。于是comparable_to?里的格式相等比较对构建号 tag 实际上是在比较它们各自的模板字符串——模板相同才可比。测试侧openjdk.json 与 multiple-intermediate-words.json 两个 fixture 恰好包含21-ea-32、22-ea-7这类 tagupdate_checker_spec.rb 断言21-ea-32的最新更新是22-ea-7。其他格式SHA 后缀与不可比较标签除上述三类Tag#format还有两个分支值得注意见 tag.rb#L156-L175:sha_suffixedtag 以 7 位以上十六进制串结尾/(^|\-g?)[0-9a-f]{7,}$/如v3.10.0-169-gfe040d3。源码注释明确这类 tag 不视为预发布见 tag.rb#L46-L47且参与比较时不比较后缀:normal其余能匹配上NAME_WITH_VERSION的标签即标准 Semver 型。完全匹配不上NAME_WITH_VERSION的 tag如latest、发行版代号artfulcomparable?返回falsefetch_latest_tag会直接原样返回该 tag不再尝试版本比较——这类滚动 tag只能通过 digest 刷新路径处理。从 tag 到更新候选UpdateChecker 管线README 描述的是什么样的 tag 可以被更新而真正执行更新决策的是 UpdateChecker。它的入口fetch_latest_tag是一条清晰的七步管线见 update_checker.rb#L298-L314candidate_tags comparable_tags_from_registry(version_tag) candidate_tags remove_version_downgrades(candidate_tags, version_tag) candidate_tags remove_more_precise_tags(candidate_tags, version_tag) candidate_tags remove_prereleases(candidate_tags, version_tag) candidate_tags filter_ignored(candidate_tags) candidate_tags sort_tags(candidate_tags, version_tag) candidate_tags apply_cooldown(candidate_tags) select_best_candidate(candidate_tags, version_tag)各步骤与 README 规则的对应关系comparable_tags_from_registry拉取注册表全部 tag用Tag#comparable_to?过滤只保留前缀/格式/后缀一致的候选——这就是 Semver 一节前缀后缀必须匹配的执行点remove_version_downgrades用numeric_version比较剔除低于当前版本的候选remove_more_precise_tags见 update_checker.rb#L639-L657如果当前 tag 只锁定到主版本或主.次版本如9.0视为滚动 tag不会主动升级到9.0.17这种更精确的 patch——这是对用户显式选择粗粒度锁定的尊重remove_prereleases当前 tag 不是预发布时剔除所有看起来像预发布的候选。Tag#looks_like_prerelease?见 tag.rb#L42-L74用一组模式alpha、beta、rc、dev、nightly、snapshot、Python PEP 440 的.post/.dev等在版本号与后缀两个位置做检查tag_spec.rb 对这些模式做了逐类验证同时确认3.14.1-slim-trixie、3.6.3-alpine这类平台后缀不是预发布filter_ignored剔除被ignore规则覆盖的版本必要时抛AllVersionsIgnoredsort_tags按comparable_version_from排序版本相同时优先与当前 tag 精度一致的候选apply_cooldown见 update_checker.rb#L434-L460通过注册表 API 取候选 tag 对应 blob 的Last-Modified头作为发布时间处于冷却期内的 tag 被跳过取不到发布时间时退化为不阻塞更新。select_best_candidate之后还会做内容级校验若候选 tag 解析出的镜像内容 digest 与当前 tag 完全相同例如滚动 tag9.0指向与9.0.11相同的镜像则视为无更新保持原 tag见 update_checker.rb#L322-L366 中的same_image_contents?检查。注册表访问的分页、超时与仓库名归一UpdateChecker对大仓库 tag 列表做了专门优化见 update_checker.rb#L76-L83Docker Hub 对超大 tag 列表源码注释举例 hexpm/elixir 约有 100 万个 tag会返回 HTTP 504因此fetch_tags_from_registry先尝试一次性拉取遇到RegistryHTTPException非 429时自动回退为按TAGS_PAGE_SIZE 100分页跟随注册表的分页链接。连接参数同样可配置见 update_checker.rb#L894-L922DEPENDABOT_DOCKER_OPEN_TIMEOUT_IN_SECONDS默认 2 秒DEPENDABOT_DOCKER_READ_TIMEOUT_IN_SECONDS默认 60 秒。仓库名归一化方面docker_repo_name见 update_checker.rb#L887-L893会把 Docker Hub 上未带命名空间的官方镜像补全为library/name再向registry.hub.docker.com查询私有源凭证则由 shared/utils/credentials_finder.rb 按注册表主机匹配docker/spec/fixtures/docker/ecr_responses/下有 ECR 凭证的模拟响应。认证/授权失败会转换为PrivateSourceAuthenticationFailure等语义化异常见 update_checker.rb#L714-L738。解析入口Dockerfile 与 YAML 清单中的镜像识别更新的前提是先从仓库文件里提取出镜像依赖。FileParser 的解析规则见 file_parser.rb#L12-L24YAML_REGEXP /^[^\.].*\.ya?ml$/i FROM /FROM/i PLATFORM /--platform\(?platform\S)/ TAG_NO_PREFIX /(?tag[\w][\w.-]{0,127})/ TAG /:#{TAG_NO_PREFIX}/ DIGEST /(?digest[0-9a-f]{64})/ FROM_LINE %r{^#{FROM}\s(#{PLATFORM}\s)?(#{REGISTRY}/)? #{IMAGE}#{TAG}?(?:sha256:#{DIGEST})?#{NAME}?}x要点Dockerfile 中匹配FROM行支持--platform前缀、registry/前缀、:tag与sha256:digest可同时出现tag 长度上限 127docker.io/前缀会被规范化掉parsed_from_line[registry] nil非 Dockerfile 的 YAML 文件按 Kubernetes/Helm 清单处理workfile_file_dependencies会递归深入任意嵌套结构查找image字段含 Helm chart 的repositorytag/version 可选registry/digest组合见 file_parser.rb#L116-L162多资源文件按---切分抓取侧SharedFileFetcher 同时收集 Dockerfile 与 YAML 文件并在解析前剥离 BOM见 shared_file_fetcher.rb#L69-L80避免 YAML 解析器在 BOM 上失败。更新落地由 FileUpdater 完成它以FROM_REGEX /FROM(\s--platform\\S)?/i定位行首FROM把registry/前缀视为可选docker.io/视为隐式只替换 tag 或 digest 部分保持原有行格式。Dockerfile 样例如 dockerfiles/multi_stage_different_tags验证了多阶段构建中不同 tag 的独立更新。关键源码与测试索引内容路径生态说明与本地运行步骤docker/README.md标签解析与格式判断docker/lib/dependabot/docker/tag.rb版本排序含 Java 更新号docker/lib/dependabot/docker/version.rb更新候选管线与注册表访问docker/lib/dependabot/docker/update_checker.rbDockerfile/YAML 镜像提取docker/lib/dependabot/docker/file_parser.rb文件更新仅替换 tag/digestdocker/lib/dependabot/docker/file_updater.rbdocker 与 docker_compose 打包dependabot-docker.gemspec、dependabot-docker_compose.gemspecTag 行为测试docker/spec/dependabot/docker/tag_spec.rb注册表 tag fixturedocker/spec/fixtures/docker/registry_tags/小结docker生态的更新逻辑可以概括为三层解析层从 Dockerfile 与 Kubernetes/Helm YAML 中提取镜像引用比较层由Tag类把 tag 分解为前缀、版本、后缀与格式semver/日期/构建号/SHA 后缀用模板相等规则界定哪些 tag 之间有可比性决策层由UpdateChecker按降序剔除、精度约束、预发布过滤、冷却期与内容 digest 校验选出真正值得发 PR 的候选。README 中的三类标签模式并非孤立规则而是Tag#format的分支与comparable_to?的约束在执行管线中的具体体现——理解这条从正则到 PR 的链路就能准确预判 Dependabot 对某种自定义镜像命名方案会不会更新、更新到哪。【免费下载链接】dependabot-core Dependabots core logic for creating update PRs.项目地址: https://gitcode.com/GitHub_Trending/de/dependabot-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考