Renovate rust-version 数据源从 manifests.txt 解析 Rust 编译器版本的完整指南【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 的rust-version数据源datasource用于发现官方 Rust 编译器的全部可用版本——包括稳定版、Beta 版与带日期的 nightly 构建。本文基于仓库中 rust-version 数据源文档 展开结合该模块的 核心实现、URL 解析逻辑 以及配套的 rust-release-channel 版本方案 源码系统讲解其数据获取原理、版本提取规则、时间戳处理、版本化语义以及如何将它用于 rust-toolchain 等实际场景。数据源概览rust-version是 Renovate 内置数据源之一其类定义为RustVersionDatasource注册 id 为rust-version见 index.ts。它只负责一件事从 Rust 官方分发基础设施的单一索引文件https://static.rust-lang.org/manifests.txt中读取所有历史发布清单的 URL并据此生成可供 Renovate 排程的发布版本列表。与大多数逐个拉取包元数据的数据源不同rust-version刻意避免了逐一下载每个 manifest TOML 文件而是直接从清单 URL 中按模式提取版本号。该数据源的几个关键特征如下表所示特征值说明Datasource idrust-version在配置中以datasourcerust-version引用默认 registryhttps://static.rust-lang.org从defaultRegistryUrls读取源码数据入口registry/manifests.txt通过new URL(manifests.txt, registryUrl)拼接源码默认版本方案rust-release-channel见 rust-release-channel 版本方案自定义 registry不支持customRegistrySupport false源码发布时间戳支持直接从 manifest URL 中的日期解析源码结果缓存启用通过withCache按 registryUrl 缓存源码此外数据源返回的ReleaseResult还会附带homepagehttps://rust-lang.org/、sourceUrlRust 官方仓库与changelogUrlRELEASES.md供 Renovate 在生成 PR 时引用源码。工作原理单文件驱动的发布发现数据获取流程整个发现过程非常简洁可分为四步对应 getManifests 与 _getReleases拉取索引向https://static.rust-lang.org/manifests.txt发起 HTTP GET返回纯文本响应体逐行解析将响应体按\n切分为行跳过空行与纯空白行对每一行调用parseManifestUrl()提取{ date, version }结构过滤与去重剔除stable、beta这类无日期标识的频道记录rust-release-channel版本方案不支持它们并按版本去重、保留每个版本的最新日期组装发布列表将 nightly 版本拼接为nightly-YYYY-MM-DD形式把日期字符串转换为 UTC 时间戳最终返回ReleaseResult。getReleases()作为对外入口会先经过withCache包装——缓存命名空间为datasource-rust-version缓存键为registryUrl源码。这意味着同一 registry 的 manifests 拉取结果会在缓存周期内被复用避免重复请求官方基础设施。解析正则版本提取的核心是 parse.ts 中的一段宽松正则(?date\d{4}-\d{2}-\d{2})\/channel-rust-(?version.?)\.toml$它要求 URL 同时满足两个条件包含YYYY-MM-DD格式的日期且以channel-rust-{identifier}.toml结尾。version捕获组使用非贪婪匹配.?因此能兼容nightly、1.82.0、1.83.0-beta.5等多种标识符。匹配失败时函数返回null。从单元测试 parse.spec.ts 可以观察到该正则的行为边界支持带https://、http://前缀的完整 URL也支持裸主机名形式的 URL支持任意域名如example.com/archives/...不局限于static.rust-lang.org缺少日期、缺少channel-rust模式、空字符串都会返回null日期仅做格式校验不做语义校验——2025-13-45这样的非法日期也能被解析测试用例明确断言了这一宽容行为。版本映射与过滤_getReleases中有一个容易被忽略但至关重要的过滤步骤源码const filteredResults parsedResults.filter( (result) result.version ! stable result.version ! beta, );manifests.txt里每天都会出现channel-rust-stable.toml与channel-rust-beta.toml两条记录它们代表的是当前最新稳定/测试频道这一浮动指针而不是具体版本。由于rust-release-channel版本方案无法把它们当作可发布的版本处理数据源会将其剔除。接着通过Map以版本字符串为键做去重后写入的即 manifests 中日期更新的记录会覆盖旧记录从而保留每个版本的最新日期源码。这正是测试用例 deduplicates versions with latest dateindex.spec.ts所验证的行为同一版本1.82.0在三个日期出现时只输出日期最新的那一条。支持的版本类型数据源最终输出的版本只包含三类 Rust 发布见 readme.mdStable 稳定版1.81.0、1.82.0等对应完整的 semver 版本号Beta 测试版1.83.0-beta.4、1.83.0-beta.5等带beta预发布标记及序号Dated nightlies 带日期构建nightly-2025-11-23、nightly-2025-11-24等由频道名加发布日期组成。版本提取规则与示例manifest URL 遵循统一的目录与命名模式static.rust-lang.org/dist/YYYY-MM-DD/channel-rust-{identifier}.toml仓库文档与测试共同给出了三类典型映射manifest URL示例提取出的版本static.rust-lang.org/dist/2025-11-24/channel-rust-nightly.tomlnightly-2025-11-24static.rust-lang.org/dist/2024-10-17/channel-rust-1.82.0.toml1.82.0static.rust-lang.org/dist/2025-01-15/channel-rust-1.83.0-beta.5.toml1.83.0-beta.5注意 nightly 的转换细节parseManifestUrl对 nightly 行只返回{ date: 2025-11-24, version: nightly }parse.spec.ts而_getReleases在组装时将其拼接为nightly-${parsed.date}源码。也就是说带日期是 nightly 版本被认可的前提——这一点与 rustup 工具链命名规范完全一致。发布时间戳Release Timestamps发布时间的来源非常简单直接取 manifest URL 中的日期转换为午夜 UTC 时间戳。例如2025-11-24会映射为2025-11-24T00:00:00.000Zindex.spec.ts 中对此有明确断言。实现上通过asTimestamp(date)完成转换源码。需要说明的是这只是一个日级别的近似时间——它反映的是该构建随官方分发出现的日期而非源码提交或编译完成的精确时刻。对于 Renovate 的minimumReleaseAge最小发布年龄等依赖时间的功能这种精度通常是足够的但在配置时应了解这一粒度限制。rust-release-channel 版本方案rust-version数据源默认挂接的版本方案是rust-release-channel注册 id 见 index.ts它专门用于理解 rustup 风格的工具链标识符。版本方案的语义直接决定了数据源产出版本之后Renovate 如何比较、排序、判断稳定性与生成更新。以下语义均出自 rust-release-channel/readme.md并可在 index.ts 中找到对应实现。支持的格式频道名作为范围stable匹配任意稳定发布如1.82.0beta匹配任意测试发布如1.83.0-beta.5nightly匹配任意带日期的 nightly要求带日期如nightly-2025-11-24。版本化发布完整版本1.82.0、1.83.0-beta.5版本范围1.82即1.82.0 version 1.83.0Beta 范围1.83.0-beta匹配1.83.0的所有 beta 版本。带日期 nightlynightly-2025-11-24特定日期的 nightly 构建nightly-2015-05-15Rust 1.0 之前的历史 nightly。对应的解析实现位于 parse.ts它用一个单条正则解析完整工具链字符串channel[-date][-host]并支持可选的宿主host后缀。兼容性分组nightly 只与 nightly 兼容stable 与 beta 之间相互兼容。该规则直接影响 Renovate 会提供哪些升级建议。实现位于isCompatible()源码首先要求宿主三元组一致然后检查两边的是否 nightly状态相同。稳定性判定只有不带任何预发布后缀的最终版本才算稳定isStable()源码1.82.0→ 稳定1.83.0-beta.5→ 非稳定nightly-2025-11-24→ 非稳定。范围策略该版本方案声明支持pin与replace两种范围策略源码。pin始终钉死为精确的新版本例如stable→1.83.0nightly→nightly-2025-11-24。replace保持当前值的格式风格getNewValue 实现当前值替换为stablestablebetabetanightlynightlynightly-2025-11-23nightly-2025-11-241.821.831.82.01.83.01.83.0-beta1.84.0-beta1.83.0-beta.11.83.0-beta.5从实现可以看到无 patch 的当前值1.82会生成无 patch 的新范围major.minor无序号 beta 的当前值1.83.0-beta会生成新的 beta 范围而带日期的 nightly 与pin策略则直接返回精确的newVersion。主次版本号提取版本化发布直接从 semver 提取1.82.0→ major1, minor82, patch0忽略预发布部分1.83.0-beta.5→ major1, minor83, patch0。nightly按日期判断 major——早于 2015-05-15Rust 1.0 发布日源码中以DateTime.utc(2015, 5, 15)常量定义见 index.ts的 nightly 为 major0之后的为 major1minor 与 patch 均为nullgetMajor/getMinor/getPatch 实现。排序规则nightly 之间按日期排序、版本化发布之间按 semver 排序并且所有 nightly 恒大于所有版本化发布util.ts 的 sortParsed。预发布版本小于对应的正式版本beta 序号用于预发布之间的比较。这套排序规则保证了getSatisfyingVersion、minSatisfyingVersion等范围查询能给出确定性的结果。实际应用rust-toolchain 管理器rust-version数据源最常见的落地场景是 rust-toolchain 管理器它负责解析仓库中的rust-toolchain.toml文件。在 extract.ts 中可以看到import { RustVersionDatasource } from ../../datasource/rust-version/index.ts; import * as rustVersioning from ../../versioning/rust-release-channel/index.ts;提取出的依赖会标注datasource: RustVersionDatasource.id即rust-version见 extract.ts同时挂接rust-release-channel版本方案。这样当仓库里的rust-toolchain.toml声明了channel stable或channel 1.82.0时Renovate 便能用rust-version数据源获取全部可用版本用rust-release-channel版本方案判断当前值属于哪个频道、哪些版本可兼容、如何按pin/replace策略生成新值在 nightly 频道内只建议升级到更新的 nightly在 stable/beta 频道内则按 semver 逻辑建议升级。类似地asdf、mise、proto等通用工具链管理器也将 Rust 工具链映射到该数据源可在 asdf 管理器、mise 管理器、proto 管理器 中检索到rust-version引用。测试覆盖与行为保证该数据源的行为由两层测试锁定parse.spec.ts14 个用例覆盖 nightly/稳定/beta/频道 URL 的解析、协议前缀、非法输入缺日期、缺模式、空串、畸形日期以及跨域 URLindex.spec.ts通过httpMock模拟manifests.txt响应验证完整链路——含过滤掉stable/beta频道记录断言最终只有 3 条发布、按最新日期去重、忽略异常 URL 行invalid.toml不产生发布、静默跳过空行不产生多余告警以及网络错误时抛出external-host-error。这些测试为数据源的稳定行为提供了可验证的契约也恰好是对本文前述各小节行为描述的最直接佐证。使用前提与注意事项依赖官方基础设施数据源强依赖static.rust-lang.org/manifests.txt的可用性与格式且不支持自定义 registrycustomRegistrySupport false若该地址不可达会抛出external-host-error见 index.spec.ts。时间戳为日级别发布时间的精度只到天UTC 午夜需要精确到分钟级发布时间的功能不受支持。频道指针被过滤stable/beta浮动频道不会作为可更新版本出现在发布列表中只有具体版本号与带日期的 nightly 才会进入更新候选。兼容性分组nightly 与 stable/beta 之间不会互相建议升级这是rust-release-channel版本方案的既定语义配置更新规则时应予以考虑。如需进一步研究实现细节可直接阅读 rust-version 模块 下的全部源码与测试以及配套的 rust-release-channel 版本方案 目录。 /DSMLparameter /DSMLinvoke【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Renovate rust-version 数据源：从 manifests.txt 解析 Rust 编译器版本的完整指南
Renovate rust-version 数据源从 manifests.txt 解析 Rust 编译器版本的完整指南【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 的rust-version数据源datasource用于发现官方 Rust 编译器的全部可用版本——包括稳定版、Beta 版与带日期的 nightly 构建。本文基于仓库中 rust-version 数据源文档 展开结合该模块的 核心实现、URL 解析逻辑 以及配套的 rust-release-channel 版本方案 源码系统讲解其数据获取原理、版本提取规则、时间戳处理、版本化语义以及如何将它用于 rust-toolchain 等实际场景。数据源概览rust-version是 Renovate 内置数据源之一其类定义为RustVersionDatasource注册 id 为rust-version见 index.ts。它只负责一件事从 Rust 官方分发基础设施的单一索引文件https://static.rust-lang.org/manifests.txt中读取所有历史发布清单的 URL并据此生成可供 Renovate 排程的发布版本列表。与大多数逐个拉取包元数据的数据源不同rust-version刻意避免了逐一下载每个 manifest TOML 文件而是直接从清单 URL 中按模式提取版本号。该数据源的几个关键特征如下表所示特征值说明Datasource idrust-version在配置中以datasourcerust-version引用默认 registryhttps://static.rust-lang.org从defaultRegistryUrls读取源码数据入口registry/manifests.txt通过new URL(manifests.txt, registryUrl)拼接源码默认版本方案rust-release-channel见 rust-release-channel 版本方案自定义 registry不支持customRegistrySupport false源码发布时间戳支持直接从 manifest URL 中的日期解析源码结果缓存启用通过withCache按 registryUrl 缓存源码此外数据源返回的ReleaseResult还会附带homepagehttps://rust-lang.org/、sourceUrlRust 官方仓库与changelogUrlRELEASES.md供 Renovate 在生成 PR 时引用源码。工作原理单文件驱动的发布发现数据获取流程整个发现过程非常简洁可分为四步对应 getManifests 与 _getReleases拉取索引向https://static.rust-lang.org/manifests.txt发起 HTTP GET返回纯文本响应体逐行解析将响应体按\n切分为行跳过空行与纯空白行对每一行调用parseManifestUrl()提取{ date, version }结构过滤与去重剔除stable、beta这类无日期标识的频道记录rust-release-channel版本方案不支持它们并按版本去重、保留每个版本的最新日期组装发布列表将 nightly 版本拼接为nightly-YYYY-MM-DD形式把日期字符串转换为 UTC 时间戳最终返回ReleaseResult。getReleases()作为对外入口会先经过withCache包装——缓存命名空间为datasource-rust-version缓存键为registryUrl源码。这意味着同一 registry 的 manifests 拉取结果会在缓存周期内被复用避免重复请求官方基础设施。解析正则版本提取的核心是 parse.ts 中的一段宽松正则(?date\d{4}-\d{2}-\d{2})\/channel-rust-(?version.?)\.toml$它要求 URL 同时满足两个条件包含YYYY-MM-DD格式的日期且以channel-rust-{identifier}.toml结尾。version捕获组使用非贪婪匹配.?因此能兼容nightly、1.82.0、1.83.0-beta.5等多种标识符。匹配失败时函数返回null。从单元测试 parse.spec.ts 可以观察到该正则的行为边界支持带https://、http://前缀的完整 URL也支持裸主机名形式的 URL支持任意域名如example.com/archives/...不局限于static.rust-lang.org缺少日期、缺少channel-rust模式、空字符串都会返回null日期仅做格式校验不做语义校验——2025-13-45这样的非法日期也能被解析测试用例明确断言了这一宽容行为。版本映射与过滤_getReleases中有一个容易被忽略但至关重要的过滤步骤源码const filteredResults parsedResults.filter( (result) result.version ! stable result.version ! beta, );manifests.txt里每天都会出现channel-rust-stable.toml与channel-rust-beta.toml两条记录它们代表的是当前最新稳定/测试频道这一浮动指针而不是具体版本。由于rust-release-channel版本方案无法把它们当作可发布的版本处理数据源会将其剔除。接着通过Map以版本字符串为键做去重后写入的即 manifests 中日期更新的记录会覆盖旧记录从而保留每个版本的最新日期源码。这正是测试用例 deduplicates versions with latest dateindex.spec.ts所验证的行为同一版本1.82.0在三个日期出现时只输出日期最新的那一条。支持的版本类型数据源最终输出的版本只包含三类 Rust 发布见 readme.mdStable 稳定版1.81.0、1.82.0等对应完整的 semver 版本号Beta 测试版1.83.0-beta.4、1.83.0-beta.5等带beta预发布标记及序号Dated nightlies 带日期构建nightly-2025-11-23、nightly-2025-11-24等由频道名加发布日期组成。版本提取规则与示例manifest URL 遵循统一的目录与命名模式static.rust-lang.org/dist/YYYY-MM-DD/channel-rust-{identifier}.toml仓库文档与测试共同给出了三类典型映射manifest URL示例提取出的版本static.rust-lang.org/dist/2025-11-24/channel-rust-nightly.tomlnightly-2025-11-24static.rust-lang.org/dist/2024-10-17/channel-rust-1.82.0.toml1.82.0static.rust-lang.org/dist/2025-01-15/channel-rust-1.83.0-beta.5.toml1.83.0-beta.5注意 nightly 的转换细节parseManifestUrl对 nightly 行只返回{ date: 2025-11-24, version: nightly }parse.spec.ts而_getReleases在组装时将其拼接为nightly-${parsed.date}源码。也就是说带日期是 nightly 版本被认可的前提——这一点与 rustup 工具链命名规范完全一致。发布时间戳Release Timestamps发布时间的来源非常简单直接取 manifest URL 中的日期转换为午夜 UTC 时间戳。例如2025-11-24会映射为2025-11-24T00:00:00.000Zindex.spec.ts 中对此有明确断言。实现上通过asTimestamp(date)完成转换源码。需要说明的是这只是一个日级别的近似时间——它反映的是该构建随官方分发出现的日期而非源码提交或编译完成的精确时刻。对于 Renovate 的minimumReleaseAge最小发布年龄等依赖时间的功能这种精度通常是足够的但在配置时应了解这一粒度限制。rust-release-channel 版本方案rust-version数据源默认挂接的版本方案是rust-release-channel注册 id 见 index.ts它专门用于理解 rustup 风格的工具链标识符。版本方案的语义直接决定了数据源产出版本之后Renovate 如何比较、排序、判断稳定性与生成更新。以下语义均出自 rust-release-channel/readme.md并可在 index.ts 中找到对应实现。支持的格式频道名作为范围stable匹配任意稳定发布如1.82.0beta匹配任意测试发布如1.83.0-beta.5nightly匹配任意带日期的 nightly要求带日期如nightly-2025-11-24。版本化发布完整版本1.82.0、1.83.0-beta.5版本范围1.82即1.82.0 version 1.83.0Beta 范围1.83.0-beta匹配1.83.0的所有 beta 版本。带日期 nightlynightly-2025-11-24特定日期的 nightly 构建nightly-2015-05-15Rust 1.0 之前的历史 nightly。对应的解析实现位于 parse.ts它用一个单条正则解析完整工具链字符串channel[-date][-host]并支持可选的宿主host后缀。兼容性分组nightly 只与 nightly 兼容stable 与 beta 之间相互兼容。该规则直接影响 Renovate 会提供哪些升级建议。实现位于isCompatible()源码首先要求宿主三元组一致然后检查两边的是否 nightly状态相同。稳定性判定只有不带任何预发布后缀的最终版本才算稳定isStable()源码1.82.0→ 稳定1.83.0-beta.5→ 非稳定nightly-2025-11-24→ 非稳定。范围策略该版本方案声明支持pin与replace两种范围策略源码。pin始终钉死为精确的新版本例如stable→1.83.0nightly→nightly-2025-11-24。replace保持当前值的格式风格getNewValue 实现当前值替换为stablestablebetabetanightlynightlynightly-2025-11-23nightly-2025-11-241.821.831.82.01.83.01.83.0-beta1.84.0-beta1.83.0-beta.11.83.0-beta.5从实现可以看到无 patch 的当前值1.82会生成无 patch 的新范围major.minor无序号 beta 的当前值1.83.0-beta会生成新的 beta 范围而带日期的 nightly 与pin策略则直接返回精确的newVersion。主次版本号提取版本化发布直接从 semver 提取1.82.0→ major1, minor82, patch0忽略预发布部分1.83.0-beta.5→ major1, minor83, patch0。nightly按日期判断 major——早于 2015-05-15Rust 1.0 发布日源码中以DateTime.utc(2015, 5, 15)常量定义见 index.ts的 nightly 为 major0之后的为 major1minor 与 patch 均为nullgetMajor/getMinor/getPatch 实现。排序规则nightly 之间按日期排序、版本化发布之间按 semver 排序并且所有 nightly 恒大于所有版本化发布util.ts 的 sortParsed。预发布版本小于对应的正式版本beta 序号用于预发布之间的比较。这套排序规则保证了getSatisfyingVersion、minSatisfyingVersion等范围查询能给出确定性的结果。实际应用rust-toolchain 管理器rust-version数据源最常见的落地场景是 rust-toolchain 管理器它负责解析仓库中的rust-toolchain.toml文件。在 extract.ts 中可以看到import { RustVersionDatasource } from ../../datasource/rust-version/index.ts; import * as rustVersioning from ../../versioning/rust-release-channel/index.ts;提取出的依赖会标注datasource: RustVersionDatasource.id即rust-version见 extract.ts同时挂接rust-release-channel版本方案。这样当仓库里的rust-toolchain.toml声明了channel stable或channel 1.82.0时Renovate 便能用rust-version数据源获取全部可用版本用rust-release-channel版本方案判断当前值属于哪个频道、哪些版本可兼容、如何按pin/replace策略生成新值在 nightly 频道内只建议升级到更新的 nightly在 stable/beta 频道内则按 semver 逻辑建议升级。类似地asdf、mise、proto等通用工具链管理器也将 Rust 工具链映射到该数据源可在 asdf 管理器、mise 管理器、proto 管理器 中检索到rust-version引用。测试覆盖与行为保证该数据源的行为由两层测试锁定parse.spec.ts14 个用例覆盖 nightly/稳定/beta/频道 URL 的解析、协议前缀、非法输入缺日期、缺模式、空串、畸形日期以及跨域 URLindex.spec.ts通过httpMock模拟manifests.txt响应验证完整链路——含过滤掉stable/beta频道记录断言最终只有 3 条发布、按最新日期去重、忽略异常 URL 行invalid.toml不产生发布、静默跳过空行不产生多余告警以及网络错误时抛出external-host-error。这些测试为数据源的稳定行为提供了可验证的契约也恰好是对本文前述各小节行为描述的最直接佐证。使用前提与注意事项依赖官方基础设施数据源强依赖static.rust-lang.org/manifests.txt的可用性与格式且不支持自定义 registrycustomRegistrySupport false若该地址不可达会抛出external-host-error见 index.spec.ts。时间戳为日级别发布时间的精度只到天UTC 午夜需要精确到分钟级发布时间的功能不受支持。频道指针被过滤stable/beta浮动频道不会作为可更新版本出现在发布列表中只有具体版本号与带日期的 nightly 才会进入更新候选。兼容性分组nightly 与 stable/beta 之间不会互相建议升级这是rust-release-channel版本方案的既定语义配置更新规则时应予以考虑。如需进一步研究实现细节可直接阅读 rust-version 模块 下的全部源码与测试以及配套的 rust-release-channel 版本方案 目录。 /DSMLparameter /DSMLinvoke【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考