Renovate rust-toolchain 管理器自动化更新 rust-toolchain.toml 与 rust-toolchain 工具链版本【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本文以 Renovate 源码仓库中的 rust-toolchain 管理器文档 为主体系统讲解它如何识别并更新rust-toolchain.toml与 legacy 纯文本rust-toolchain文件中的 Rust 工具链版本包括文件匹配规则、TOML/纯文本两种格式的提取逻辑、支持的全部升级场景含rangeStrategy: pin下的固定化行为、版本兼容分组以及跳过更新的边界情况与源码级依据。读完本文你可以完整配置该项目并准确判断 Renovate 对任意一份 rust-toolchain 文件会做出什么更新决定。管理器定位与文件识别rust-toolchain 管理器的官方定位是更新rust-toolchain.toml和rust-toolchain两类文件中的 Rust 工具链版本。它同时支持 TOML 格式和 rustup 规范定义的 legacy 纯文本格式即文件内只有一行工具链名例如1.90.0或stable。该管理器的元数据与默认配置定义在 index.ts 中几个关键点直接决定了它的行为displayNameRust ToolchaindefaultConfig.managerFilePatterns[/(^|/)rust-toolchain(\\.toml)?$/]——即只有路径以rust-toolchain或rust-toolchain.toml结尾的文件才会被该管理器接管任意目录层级都生效(^|/)前缀保证rust-toolchain是完整路径段不会误伤xrust-toolchain.toml之类文件名defaultConfig.commitMessageTopicRust——提交信息与 PR 标题中的主题词统一为 Rust便于在大量升级 PR 中识别工具链更新supportedDatasources仅注册了rust-version数据源即工具链版本信息的唯一来源是 rust-version 数据源depType提取出的依赖类型固定为toolchain这一点被 dep-types.ts 中的knownDepTypes声明也是文档中Version pinning配置用matchDepTypes: [toolchain]生效的依据。支持的文件格式与提取逻辑提取入口是 extract.ts 的extractPackageFile()其策略是先尝试 TOML 解析失败再回退 legacy 纯文本格式。TOML 格式只关心 [toolchain] 表的 channel 与 pathTOML 解析由 schema.ts 中的 Zod schema 完成export const RustToolchain Toml.pipe( z.object({ toolchain: z.object({ channel: z.string().optional(), path: z.string().optional(), }), }), );该 schema 强制要求顶层存在[toolchain]表但channel与path均为可选字符串components、targets等其他字段被直接忽略schema.spec.ts 中parses TOML with additional fields用例验证了含components/targets的文件解析结果中只保留channel。因此一份典型的受管文件长这样[toolchain] channel 1.89.1 components [rustfmt, clippy] targets [wasm32-unknown-unknown]Renovate 提取出的依赖对象为{ depName: rust, depType: toolchain, currentValue: 1.89.1, datasource: rust-version, }这与 extract.spec.ts 中的断言完全一致且测试覆盖了1.89.1完整版本、1.89major.minor 范围、stable/beta/nightly通道名、nightly-2025-10-12带日期的 nightly等多种取值形态。提取逻辑对channel与path的优先级及跳过条件处理如下均在 extract.ts 中文件内容提取结果说明channel 1.89.1正常提取依赖最常见场景channel与path同时存在优先使用channel测试用例prefers channel over path when both are set仅path /path/to/toolchainskipReason: path-dependency本地路径工具链无法更新Renovate 会记录 debug 日志channel缺失或为空字符串skipReason: unspecified-version文件可解析但无可更新的版本值channel为无法识别的值如not-a-rust-channelskipReason: invalid-version由rust-release-channel版本方案的isValid()判定createDependency()中非法 TOML 或缺少[toolchain]表返回null不产生依赖且不会触发告警日志测试中logger.logger.warn断言为未调用legacy 纯文本格式仅限非 .toml 文件的单行内容当 TOML 解析失败时extract.ts 会回退到 legacy 解析但有严格约束仅当文件名不以.toml结尾时才回退。对rust-toolchain.toml而言 TOML 解析必须成功否则直接返回null——这避免了把格式错误的 toml 文件误当作纯文本处理内容按行拆分、去除空白后必须恰好只剩一行。空文件、多行文件如两行版本号都会返回null这一行就是currentValue同样会经过rust-release-channel的isValid()校验非法值得到invalid-version跳过原因。对应测试用例extract.spec.ts1.89.1\n→ 正常提取not-a-rust-channel\n→invalid-version多行内容 →null。版本来源rust-version 数据源工具链版本目录来自 rust-version 数据源它从官方 Rust 发布基础设施的static.rust-lang.org/manifests.txt拉取按时间排列的 manifest 文件 URL 列表并用正则从 URL 模式dist/YYYY-MM-DD/channel-rust-{identifier}.toml中直接解析出版本而不是逐个抓取 manifest。该数据源只返回三类版本Stable 正式发布1.81.0、1.82.0等Beta 发布1.83.0-beta.4、1.83.0-beta.5等带日期的 nightlynightly-2025-11-23、nightly-2025-11-24等。发布时间戳取自 manifest URL 中的日期精度到天UTC 零点。数据源声明使用rust-release-channel版本方案做版本比较与更新决策。支持的更新场景Supported renovations这是原文档的核心内容。在默认非 pin策略下rust-toolchain 管理器支持以下升级1.90.0→2.0.0major 升级1.90.0→1.91.0minor 升级1.90.0→1.90.1patch 升级1.90→2.0major 范围升级1.90→1.91minor 范围升级nightly-2025-10-10→nightly-2025-10-11带日期 nightly 的日期滚动启用rangeStrategy: pin后额外支持把范围/通道固定为具体版本1.90→1.90.0范围固定化stable→1.90.0stable 通道固定化nightly→nightly-2025-10-11nightly 通道固定化注以上版本号仅为示例实际值取决于当前 Rust 发布情况。背后的版本方案rust-release-channel上述哪些能升、哪些不升的边界由 rust-release-channel 版本方案 决定值得展开对照理解支持的取值形态通道名范围stable匹配任意 stable 发布如1.82.0、beta匹配任意 beta 发布如1.83.0-beta.5、nightly匹配任意带日期 nightly如nightly-2025-11-24版本化发布完整版本1.82.0、1.83.0-beta.5范围1.82语义为1.82.0 版本 1.83.0beta 范围1.83.0-beta匹配1.83.0的所有 beta带日期 nightlynightly-2025-11-24甚至覆盖 Rust 1.0 之前的历史 nightly如nightly-2015-05-15。兼容分组直接影响 Renovate 提供哪些更新nightly 版本只与 nightly 互兼容——因此nightly-2025-10-10只会向更近的日期滚动而不会向 stable 版本跳变stable 与 beta 版本互兼容——因此 beta 项目可以看到 stable 更新。稳定性的判定只有不带预发布后缀的正式发布才算 stable1.82.0是 stable1.83.0-beta.5与nightly-2025-11-24都不是。这解释了为什么文档中stable/beta/nightly这类通道名本身可以被固定化而带日期的 nightly 只能向日期递进。两种 rangeStrategy 的行为差异版本方案文档中的定义pin总是固定到确切的新版本——stable→1.83.0nightly→nightly-2025-11-24replace默认保持当前值的书写风格——stable→stable、nightly-2025-11-23→nightly-2025-11-24、1.82→1.83、1.82.0→1.83.0。版本固定Version pinning配置如果你希望把工具链固定到具体版本例如让stable或1.90这类不确定的写法落为精确版本号原文档给出的配置如下{ packageRules: [ { matchManagers: [rust-toolchain], matchDepTypes: [toolchain], rangeStrategy: pin } ] }三个匹配条件的来源都可在源码中确认matchManagers命中管理器的模块名rust-toolchain即 api.ts 注册的键matchDepTypes命中该管理器唯一的依赖类型toolchain见 dep-types.tsrangeStrategy: pin则触发版本方案文档中定义的固定化行为产生1.90→1.90.0、stable→1.90.0、nightly→nightly-2025-10-11这类变更。不添加该规则时Renovate 默认按replace策略保持原有书写风格stable这类通道名会被保留不变。边界情况小结与验证入口综合 extract.ts、schema.ts 及测试用例可以整理出该管理器的完整行为矩阵场景文件形态结果TOML 含channel[toolchain] channel 1.89.1正常更新TOML 仅含path本地工具链跳过path-dependencyTOML 无channel或为空只配了components等跳过unspecified-version非法通道值channel not-a-rust-channel跳过invalid-version.toml文件但 TOML 非法 / 缺[toolchain]表解析失败不提取依赖返回null非.toml文件、合法单行1.89.1正常更新legacy 格式非.toml文件、空或多行空文件 / 两行版本不提取依赖返回null上述每个分支都有对应的测试用例覆盖TOML 解析分支见 schema.spec.ts提取分支见 extract.spec.ts可用作验证管理器行为的第一手依据。适用前提与限制该管理器只处理文件名恰为rust-toolchain或rust-toolchain.toml的文件把工具链写在其他配置文件里如 Makefile 或 CI 脚本中的环境变量不在本管理器范围内只有[toolchain]表中的channel字段可更新components、targets、profile等字段均不被修改path指向的本地工具链被明确视为不可更新版本比较与升级范围完全依赖rust-release-channel版本方案的兼容分组规则nightly 与 stable/beta 互不相通如果你的通道写法不在该方案支持列表内例如拼写错误的自定义通道会得到invalid-version跳过而不会报错数据源版本目录来自 Rust 官方发布清单因此 beta 与 nightly 的可见性、发布时间精度到天均以该清单为准。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Renovate rust-toolchain 管理器：自动化更新 rust-toolchain.toml 与 rust-toolchain 工具链版本
Renovate rust-toolchain 管理器自动化更新 rust-toolchain.toml 与 rust-toolchain 工具链版本【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本文以 Renovate 源码仓库中的 rust-toolchain 管理器文档 为主体系统讲解它如何识别并更新rust-toolchain.toml与 legacy 纯文本rust-toolchain文件中的 Rust 工具链版本包括文件匹配规则、TOML/纯文本两种格式的提取逻辑、支持的全部升级场景含rangeStrategy: pin下的固定化行为、版本兼容分组以及跳过更新的边界情况与源码级依据。读完本文你可以完整配置该项目并准确判断 Renovate 对任意一份 rust-toolchain 文件会做出什么更新决定。管理器定位与文件识别rust-toolchain 管理器的官方定位是更新rust-toolchain.toml和rust-toolchain两类文件中的 Rust 工具链版本。它同时支持 TOML 格式和 rustup 规范定义的 legacy 纯文本格式即文件内只有一行工具链名例如1.90.0或stable。该管理器的元数据与默认配置定义在 index.ts 中几个关键点直接决定了它的行为displayNameRust ToolchaindefaultConfig.managerFilePatterns[/(^|/)rust-toolchain(\\.toml)?$/]——即只有路径以rust-toolchain或rust-toolchain.toml结尾的文件才会被该管理器接管任意目录层级都生效(^|/)前缀保证rust-toolchain是完整路径段不会误伤xrust-toolchain.toml之类文件名defaultConfig.commitMessageTopicRust——提交信息与 PR 标题中的主题词统一为 Rust便于在大量升级 PR 中识别工具链更新supportedDatasources仅注册了rust-version数据源即工具链版本信息的唯一来源是 rust-version 数据源depType提取出的依赖类型固定为toolchain这一点被 dep-types.ts 中的knownDepTypes声明也是文档中Version pinning配置用matchDepTypes: [toolchain]生效的依据。支持的文件格式与提取逻辑提取入口是 extract.ts 的extractPackageFile()其策略是先尝试 TOML 解析失败再回退 legacy 纯文本格式。TOML 格式只关心 [toolchain] 表的 channel 与 pathTOML 解析由 schema.ts 中的 Zod schema 完成export const RustToolchain Toml.pipe( z.object({ toolchain: z.object({ channel: z.string().optional(), path: z.string().optional(), }), }), );该 schema 强制要求顶层存在[toolchain]表但channel与path均为可选字符串components、targets等其他字段被直接忽略schema.spec.ts 中parses TOML with additional fields用例验证了含components/targets的文件解析结果中只保留channel。因此一份典型的受管文件长这样[toolchain] channel 1.89.1 components [rustfmt, clippy] targets [wasm32-unknown-unknown]Renovate 提取出的依赖对象为{ depName: rust, depType: toolchain, currentValue: 1.89.1, datasource: rust-version, }这与 extract.spec.ts 中的断言完全一致且测试覆盖了1.89.1完整版本、1.89major.minor 范围、stable/beta/nightly通道名、nightly-2025-10-12带日期的 nightly等多种取值形态。提取逻辑对channel与path的优先级及跳过条件处理如下均在 extract.ts 中文件内容提取结果说明channel 1.89.1正常提取依赖最常见场景channel与path同时存在优先使用channel测试用例prefers channel over path when both are set仅path /path/to/toolchainskipReason: path-dependency本地路径工具链无法更新Renovate 会记录 debug 日志channel缺失或为空字符串skipReason: unspecified-version文件可解析但无可更新的版本值channel为无法识别的值如not-a-rust-channelskipReason: invalid-version由rust-release-channel版本方案的isValid()判定createDependency()中非法 TOML 或缺少[toolchain]表返回null不产生依赖且不会触发告警日志测试中logger.logger.warn断言为未调用legacy 纯文本格式仅限非 .toml 文件的单行内容当 TOML 解析失败时extract.ts 会回退到 legacy 解析但有严格约束仅当文件名不以.toml结尾时才回退。对rust-toolchain.toml而言 TOML 解析必须成功否则直接返回null——这避免了把格式错误的 toml 文件误当作纯文本处理内容按行拆分、去除空白后必须恰好只剩一行。空文件、多行文件如两行版本号都会返回null这一行就是currentValue同样会经过rust-release-channel的isValid()校验非法值得到invalid-version跳过原因。对应测试用例extract.spec.ts1.89.1\n→ 正常提取not-a-rust-channel\n→invalid-version多行内容 →null。版本来源rust-version 数据源工具链版本目录来自 rust-version 数据源它从官方 Rust 发布基础设施的static.rust-lang.org/manifests.txt拉取按时间排列的 manifest 文件 URL 列表并用正则从 URL 模式dist/YYYY-MM-DD/channel-rust-{identifier}.toml中直接解析出版本而不是逐个抓取 manifest。该数据源只返回三类版本Stable 正式发布1.81.0、1.82.0等Beta 发布1.83.0-beta.4、1.83.0-beta.5等带日期的 nightlynightly-2025-11-23、nightly-2025-11-24等。发布时间戳取自 manifest URL 中的日期精度到天UTC 零点。数据源声明使用rust-release-channel版本方案做版本比较与更新决策。支持的更新场景Supported renovations这是原文档的核心内容。在默认非 pin策略下rust-toolchain 管理器支持以下升级1.90.0→2.0.0major 升级1.90.0→1.91.0minor 升级1.90.0→1.90.1patch 升级1.90→2.0major 范围升级1.90→1.91minor 范围升级nightly-2025-10-10→nightly-2025-10-11带日期 nightly 的日期滚动启用rangeStrategy: pin后额外支持把范围/通道固定为具体版本1.90→1.90.0范围固定化stable→1.90.0stable 通道固定化nightly→nightly-2025-10-11nightly 通道固定化注以上版本号仅为示例实际值取决于当前 Rust 发布情况。背后的版本方案rust-release-channel上述哪些能升、哪些不升的边界由 rust-release-channel 版本方案 决定值得展开对照理解支持的取值形态通道名范围stable匹配任意 stable 发布如1.82.0、beta匹配任意 beta 发布如1.83.0-beta.5、nightly匹配任意带日期 nightly如nightly-2025-11-24版本化发布完整版本1.82.0、1.83.0-beta.5范围1.82语义为1.82.0 版本 1.83.0beta 范围1.83.0-beta匹配1.83.0的所有 beta带日期 nightlynightly-2025-11-24甚至覆盖 Rust 1.0 之前的历史 nightly如nightly-2015-05-15。兼容分组直接影响 Renovate 提供哪些更新nightly 版本只与 nightly 互兼容——因此nightly-2025-10-10只会向更近的日期滚动而不会向 stable 版本跳变stable 与 beta 版本互兼容——因此 beta 项目可以看到 stable 更新。稳定性的判定只有不带预发布后缀的正式发布才算 stable1.82.0是 stable1.83.0-beta.5与nightly-2025-11-24都不是。这解释了为什么文档中stable/beta/nightly这类通道名本身可以被固定化而带日期的 nightly 只能向日期递进。两种 rangeStrategy 的行为差异版本方案文档中的定义pin总是固定到确切的新版本——stable→1.83.0nightly→nightly-2025-11-24replace默认保持当前值的书写风格——stable→stable、nightly-2025-11-23→nightly-2025-11-24、1.82→1.83、1.82.0→1.83.0。版本固定Version pinning配置如果你希望把工具链固定到具体版本例如让stable或1.90这类不确定的写法落为精确版本号原文档给出的配置如下{ packageRules: [ { matchManagers: [rust-toolchain], matchDepTypes: [toolchain], rangeStrategy: pin } ] }三个匹配条件的来源都可在源码中确认matchManagers命中管理器的模块名rust-toolchain即 api.ts 注册的键matchDepTypes命中该管理器唯一的依赖类型toolchain见 dep-types.tsrangeStrategy: pin则触发版本方案文档中定义的固定化行为产生1.90→1.90.0、stable→1.90.0、nightly→nightly-2025-10-11这类变更。不添加该规则时Renovate 默认按replace策略保持原有书写风格stable这类通道名会被保留不变。边界情况小结与验证入口综合 extract.ts、schema.ts 及测试用例可以整理出该管理器的完整行为矩阵场景文件形态结果TOML 含channel[toolchain] channel 1.89.1正常更新TOML 仅含path本地工具链跳过path-dependencyTOML 无channel或为空只配了components等跳过unspecified-version非法通道值channel not-a-rust-channel跳过invalid-version.toml文件但 TOML 非法 / 缺[toolchain]表解析失败不提取依赖返回null非.toml文件、合法单行1.89.1正常更新legacy 格式非.toml文件、空或多行空文件 / 两行版本不提取依赖返回null上述每个分支都有对应的测试用例覆盖TOML 解析分支见 schema.spec.ts提取分支见 extract.spec.ts可用作验证管理器行为的第一手依据。适用前提与限制该管理器只处理文件名恰为rust-toolchain或rust-toolchain.toml的文件把工具链写在其他配置文件里如 Makefile 或 CI 脚本中的环境变量不在本管理器范围内只有[toolchain]表中的channel字段可更新components、targets、profile等字段均不被修改path指向的本地工具链被明确视为不可更新版本比较与升级范围完全依赖rust-release-channel版本方案的兼容分组规则nightly 与 stable/beta 互不相通如果你的通道写法不在该方案支持列表内例如拼写错误的自定义通道会得到invalid-version跳过而不会报错数据源版本目录来自 Rust 官方发布清单因此 beta 与 nightly 的可见性、发布时间精度到天均以该清单为准。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考