dependabot-core 的 silent 生态：一个零网络请求的“哑”包管理器与 updater 的端到端测试体系

dependabot-core 的 silent 生态：一个零网络请求的“哑”包管理器与 updater 的端到端测试体系

【免费下载链接】dependabot-core🤖 Dependabot's core logic for creating update PRs.项目地址: https://gitcode.com/GitHub_Trending/de/dependabot-core

本文以 silent/README.md 为核心，讲解 dependabot-core 中名为silent的测试专用生态（ecosystem）的完整设计：它如何用纯本地 JSON 文件模拟一个包管理器的全部组件，如何用 txtar 格式的端到端测试脚本驱动 Dependabot CLI 跑通完整的更新流程，以及如何通过 silent/tests/silent_test.go 对更新器输出的 PR 内容进行断言。读完后你能掌握为 updater 编写无网络、可复现集成测试的完整方法论，并理解 silent 生态各组件（fetcher / parser / checker / updater）与 updater 主流程的对接点。

缘起：为什么 updater 需要一个“哑”生态

silent/README.md 开宗明义：这个生态专门用于对updater代码做集成测试，真实测试用例都放在 silent/tests/testdata 目录中。

README 中给出了三条动机，都是历史痛点：

1. 早期用大型 rspec + fixtures 测试 updater。fixture 文件把单个测试的上下文拆得到处都是，“让人难以把测试当成一个整体来看”；
2. 依赖真实生态做测试等于测了太多东西。用真实的 npm、bundler 等生态去验证 updater 逻辑时，生态本身的行为也成了被测对象，干扰了断言目标；
3. 真实生态会发起真实网络请求。有些 native helper 根本无法 mock，导致测试不稳定且无法在离线环境运行。

解决方案就是造一个不发任何网络请求的新生态——这就是 "silent"（沉默）名字的由来。README 将其概括为：“它是生态的最小化实现，用包含 JSON 的文件作为可用版本的清单。”

silent 生态的实现：一切来自本地文件

silent 生态的代码位于 silent/lib/dependabot/silent/，体量极小，但完整覆盖了 Dependabot 生态需要注册的全部组件。silent/lib/dependabot/silent.rb 负责把各组件 require 进来完成注册，并额外做了两件值得注意的事：

require "dependabot/pull_request_creator/labeler" Dependabot::PullRequestCreator::Labeler .register_label_details("silent", name: "silent_package_manager", colour: "000000") require "dependabot/dependency" Dependabot::Dependency .register_production_check("silent", ->(groups) { groups.empty? || groups.include?("prod") })

前者为 silent 的 PR 注册标签（见 silent.rb#L14-L20），后者定义了“生产依赖”的判定规则——组为空或包含prod即视为生产依赖，这两处细节都是 updater 生成 PR 标签和依赖类型时依赖的钩子。

下面按 updater 的调用链顺序，逐个组件拆解其“哑”的实现方式。

版本发现：UpdateChecker 从仓库文件读取版本清单

这是整个 silent 生态的核心设计。silent/lib/dependabot/silent/update_checker.rb 中fetch_dependency_metadata方法直接从仓库工作目录读取与依赖同名的文件：

def fetch_dependency_metadata version_file = File.join(repo_contents_path, dependency.name) return { "versions" => [] } unless File.exist?(version_file) # the available versions are stored in a file in the repo # that's why this package manager is silent, makes no requests JSON.parse(File.read(version_file)) rescue JSON::ParserError raise Dependabot::DependencyFileNotParseable, T.must(dependency_files.first).path end

代码注释直接点题：“可用版本保存在仓库里的一个文件中，这就是这个包管理器叫 silent 的原因，它不发起任何请求”。每个依赖dependency-a对应的版本文件内容形如：

{ "versions": [ "1.2.3", "1.2.4", "1.2.5" ] }

在latest_version（update_checker.rb#L21-L28）中，逻辑是取available_versions的最大值，并先经过filter_ignored_versions过滤被ignore掉的版本——若过滤后为空且允许抛错，则抛出Dependabot::AllVersionsIgnored（见 update_checker.rb#L91-L97），这一异常正是测试 silent/tests/testdata/su-err-all-versions-ignored.txt 所验证的场景。此外还有两个细节：

• Git 依赖模拟：git_dependency?判断依赖版本是否为 40 位字符串（SHA 长度），若是则从版本文件的git字段取下一个版本（update_checker.rb#L76-L84），用于测试 git 依赖更新路径，对应 silent/tests/testdata/vu-group-semver-git.txt 等用例；
• 安全更新：lowest_security_fix_version复用公共的VersionFilters.filter_vulnerable_versions，结合 updater 输入中的security-advisories过滤出最低修复版本，安全更新类测试（如su-err-not-vulnerable）就建立在这条链路上。

清单解析：FileFetcher 与 FileParser

silent/lib/dependabot/silent/file_fetcher.rb 是最简单的组件——它只抓取仓库根目录下的manifest.json这一个文件：

def fetch_files [manifest].compact end def manifest fetch_file_if_present("manifest.json") end

silent/lib/dependabot/silent/file_parser.rb 的parse方法解析该 JSON，为每个键生成依赖，并支持两种形态：

JSON.parse(manifest_content).each do |name, info| dependency_set << parse_single_dependency(name, info) if info.key?("version") dependency_set << parse_multiple_dependency(name, info) if info.key?("versions") end

• 单版本形态"dependency-a": { "version": "1.2.3" }是常规用法，可选携带group字段，会进入依赖的 requirements 组（file_parser.rb#L52-L65），用于测试 dependency groups；
• 多版本形态"versions": [...]模仿 npm_and_yarn 的行为：解析成一个 Dependency，但把全部版本塞进metadata[:all_versions]（file_parser.rb#L66-L77），用于测试同一依赖出现在多处版本时的更新逻辑。

另外，ecosystem方法（file_parser.rb#L31-L48）会从 manifest 的silent.version元数据读取包管理器版本，默认"2"。对应的 silent/lib/dependabot/silent/package_manager.rb 中声明SUPPORTED_SILENT_VERSIONS为2、DEPRECATED_SILENT_VERSIONS为1——silent 生态自己也完整实现了多版本包管理器机制。

文件更新：FileUpdater 回写 manifest

silent/lib/dependabot/silent/file_updater.rb 的updated_file_content把更新后的版本写回 manifest JSON：

info["version"] = requirements(file).first&.requirement_string if info["depends-on"] # also bump dependants to the same version original_content[info["depends-on"]]["version"] = requirements(file).first&.requirement_string end

两个测试专用的小机关藏在这里：多版本更新时会删掉versions键（模拟“所有版本收敛到同一版本”）；而依赖名为dont-update-any-files时直接返回空数组（file_updater.rb#L13-L14），专门用于测试“检查出有更新但文件无变化”这类边界场景。depends-on字段则用于构造依赖间版本联动的场景。

彻底“哑”掉网络：MetadataFinder 与测试输入

silent/lib/dependabot/silent/metadata_finder.rb 的look_up_source把所有源的 hostname 硬编码为127.0.0.1：

# Use 127.0.0.1 as a non-routable hostname to avoid network requests # This ensures the silent package manager remains truly "silent" Dependabot::Source.new( provider: "example", hostname: "127.0.0.1", api_endpoint: "http://127.0.0.1/api/v3", repo: dependency.name, ... )

用不可路由的127.0.0.1作为 API 端点，即使代码路径走到“访问远程仓库”也会安全失败，从实现层面保证 silent 生态真正零外联。测试输入文件里同样遵循这一约定，例如 silent/tests/testdata/su-basic.txt 中：

source: directory: "/" provider: example hostname: 127.0.0.1 api-endpoint: http://127.0.0.1/api/v3 repo: dependabot/smoke-tests

requirement.rb 与 version.rb 则是薄封装：前者继承公共Dependabot::Requirement并按&分隔符拆分复合要求，后者继承Dependabot::Version，分别通过Dependabot::Utils注册，让通用版本/要求解析机制可以无缝复用。

如何阅读测试：txtar 脚本 + Dependabot CLI

silent/README.md 的“ How to read the tests”一节是理解 silent/tests/testdata 下 60 个用例的钥匙。测试基于rsc.io/script库，用txtar 格式的.txt文件同时定义“执行步骤”和“测试现场的文件”。

一个 txtar 测试文件的结构分三段，以 silent/tests/testdata/su-basic.txt 为例：

第一段：命令区。文件顶部是实际执行的 Dependabot CLI 命令：

dependabot update -f input.yml --local . --updater-image ghcr.io/dependabot/dependabot-updater-silent

--local .表示用当前目录（即 txtar 定义的文件现场）作为输入，--updater-image指定使用 silent 专用的 updater 镜像。随后是断言命令，例如pr-created expected.json。su-basic.txt 实际演示了三段流程：新建 PR（stderr断言输出created | dependency-a ( from 1.2.3 to 1.2.4 )）、以及两次更新已有 PR的 rebase 场景——通过input-rebase-old.yml/input-rebase-new.yml中的updating-a-pull-request: true和existing-pull-requests字段注入既有 PR 元数据（su-basic.txt#L69-L135），断言则换成pr-updated expected.json。

第二段：文件现场。用-- 文件名 --分隔符声明执行时磁盘上的文件，例如 manifest：

-- manifest.json -- { "dependency-a": { "version": "1.2.3" } }

第三段：期望输出与版本清单。断言用的expected.json（更新后 manifest 应成的样子，如1.2.5）和 silent 生态读取的可用版本文件dependency-a，加上驱动整个流程的input.yml作业输入文件：

-- input.yml -- job: package-manager: "silent" source: directory: "/" provider: example hostname: example.com api-endpoint: https://example.com/api/v3 repo: dependabot/smoke-tests

从 testdata 的文件命名可以直观看出测试覆盖面：su-*是安全更新（security-update）场景，vu-*是常规版本更新（version-update）场景，err-*是异常路径，前缀之后则是具体行为标签（group、multidir、glob、rebase、multi-ecosystem等）。silent 的价值正体现在这里：它让dependency groups、多目录、多生态、冷却期、glob 匹配这些 updater 层特性都拥有了独立的、单文件自包含的集成测试。

断言命令集

README 列出了一套刻意保持精简约小的断言命令：

还可以在任何命令前加!（如! pr-created）断言该命令应当失败——包括dependabot命令本身，这就是su-err-*系列用例验证错误路径的方式。

断言的底层实现：Go 测试驱动器

这些断言命令由 silent/tests/silent_test.go 注册并驱动。测试入口用script.Engine加载testdata/*.txt下所有用例（silent_test.go#L17-L28），Commands()中把dependabot注册为外部程序，pr-created/pr-updated注册为自定义命令（silent_test.go#L34-L43）。

prChecker（silent_test.go#L84-L165）揭示了断言的具体机制：updater 容器把每个 PR 事件以 JSON 行形式打到 stdout，驱动器逐行解析，筛出type为create_pull_request或update_pull_request的事件，再将其data.updated-dependency-files里每个文件的content反序列化为 JSON，与测试文件中声明的期望 JSON 做深度相等比较。要求该 PR 更新的文件数量恰好等于断言参数中给出的文件数，且每个文件都命中期望值——多个期望文件支持同时传入（pr <file1> [<file2>...]），用于一次 PR 更新多个 manifest 的场景。匹配失败时给出“创建了 N 个 PR 但无一匹配”或“没有创建 PR”的明确错误信息。

运行测试与镜像构建

按 silent/README.md 的“Executing the tests”一节，运行前提只有一个：安装 Docker 和 Dependabot CLI 并放入 PATH。因为 silent 生态零网络请求，测试本身不需要任何远端凭据。

• 运行全部测试：script/updater-e2e（见 script/updater-e2e）；
• 运行匹配名称的部分测试：把名字片段作为参数传入，例如script/updater-e2e group会跑完所有文件名含group的用例（如vu-group-semver.txt、su-group-pattern.txt等）。

silent 的 updater 镜像由 silent/Dockerfile 定义，只有三行有效内容：以ghcr.io/dependabot/dependabot-updater-core为基础镜像，把silent、common两个目录和updater目录拷入，其余运行时环境完全复用公共 core 镜像。这也解释了为什么测试命令要用--updater-image ghcr.io/dependabot/dependabot-updater-silent：它是 core 镜像 + silent 生态代码的最小叠加。

小结

silent 生态是 dependabot-core 中一个“以被测环境换确定性”的范例：用 8 个百行以内的 Ruby 文件实现了一个完整生态，把版本发现、要求解析、安全过滤、多版本依赖、组标记、错误路径这些 updater 真正关心的行为全部收敛到本地 JSON 文件 + txtar 脚本 + JSON 深度比较断言的闭环里。它的每个组件（update_checker.rb、file_parser.rb、file_updater.rb、metadata_finder.rb）都保留了对 updater 主流程的真实注册与调用接口，因此 silent/tests/testdata 中的 60 个用例实际验证的是完整的 updater 决策链——从文件抓取到 PR 内容生成——而测试本身可以做到离线、快速、单文件可读。这正是 silent/README.md 开头那句话的完整落地：“这个生态用于对 updater 代码做集成测试。”

【免费下载链接】dependabot-core🤖 Dependabot's core logic for creating update PRs.项目地址: https://gitcode.com/GitHub_Trending/de/dependabot-core