Renovate renovate-config 管理器详解自动更新 Preset 版本与工具约束【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 的renovate-config管理器是少数把“Renovate 自己的配置文件”当成依赖来管理的模块它负责解析renovate.json等配置文件中的extendsPreset 引用与constraints工具版本约束把已固定版本的 Preset 仓库 Tag 和 Containerbase 支持的工具版本提取为可更新的依赖。读完本文你将理解该管理器扫描哪些文件、哪些 Preset 来源受支持、为什么未固定版本的 Preset 不会被自动固定以及constraints中的工具版本是如何从配置项一路解析到 Containerbase 安装命令的。管理器定位它扫描哪些文件、支持哪些数据源renovate-config管理器是 管理器目录 中注册的一个特殊 Manager其他管理器面向package.json、go.mod等依赖清单而它面向的是Renovate 自身的配置文件。从 index.ts 的源码结构看它有两个关键定义扫描文件范围defaultConfig.managerFilePatterns取自getConfigFileNames()定义于 app-strings.ts并显式过滤掉package.json——这正对应官方文档中“package.jsonfile config 已弃用”的说明。支持的数据源supportedDatasources由三部分去重合并而成——github-tags、gitlab-tags、gitea-tags用于 Preset 仓库的版本发现以及 containerbase.ts 中allToolConfig里每个工具声明的 datasource用于工具约束的版本发现如github-releases、npm、pypi等。管理器入口为extractPackageFile(content, packageFile)extract.ts输入是配置文件内容输出是PackageFileContent即一组PackageDependency。若文件无法解析如空文件、非 JSON 对象则返回null若解析出的依赖数组为空例如文件里既没有可提取的 Preset 也没有constraints同样返回null。测试用例extract.spec.ts验证了这两点extractPackageFile(this-is-not-json-object, renovate.json)返回null仅含draftPR: true的文件也返回null且不产生任何日志。配置文件的结构由 schema.ts 中的 Zod 模式约束extends可选的字符串数组constraints可选的“键-字符串”记录packageRules[].constraints同样只接受字符串值。值得注意的是解析入口使用的是Json5封装来自 schema-utils因此renovate.json5中允许注释和尾随逗号这在 测试用例 “supports JSON5” 中有明确验证。Preset 更新规则只更新已固定版本的引用官方行为说明根据管理器 READMEreadme.md与 Shareable Config Presets 文档核心规则是Preset 的版本仅在已经固定版本号时才会被更新。例如githubuser/renovate-config#1.2.3会在1.2.4可用时更新为githubuser/renovate-config#1.2.4但githubuser/renovate-config未带#tag不会被自动固定。典型配置如下继承自官方文档的完整示例{ extends: [ githubuser/renovate-config#1.2.3, githubuser/renovate-config:group ] }第一条引用了user/renovate-config仓库并固定到 Tag1.2.3Renovate 会为其创建 Preset 仓库的 Tag 更新第二条引用了预设名group但没有#tagRenovate 不会为它生成任何更新。源码印证Preset 的解析与跳过策略extractPackageFile对extends的逐项处理逻辑在 extract.ts可归纳为一条决策链模板化 Preset 直接跳过包含{{的条目如local{{ env.PRESET_REPO }}:python-312只在运行时可解析静态提取阶段直接continue不产生依赖、不产生日志对应测试 “ignores templated presets”extract.spec.ts。解析 Preset 语法调用 parsePreset。该函数先识别来源前缀——github、gitlab、gitea、forgejo、local、npm、相对路径./、../、/开头、HTTP URL其余情况按 npm 命名空间renovate-config-*或内部预设config:、schedule:等前缀以及:name简写归类。随后按仓库正则拆出repo、presetName与tag。解析失败PRESET_INVALID的条目被记录为skipReason: invalid-value例如./foo#1.2.3相对引用不允许带#tag参见 parse.ts 的校验。来源映射到数据源supportedPresetSources 仅登记了三种来源Preset 来源前缀映射的 Datasourcegithubgithub-tagsgitlabgitlab-tagsgiteagitea-tags不在该映射中的来源local、npm、HTTP URL、相对路径等会以skipReason: unsupported-datasource记录后跳过内部预设presetSource internal则静默忽略因为内置 Preset 随 Renovate 版本演进无需单独更新。从源码结构看parsePreset虽然也识别forgejo前缀但当前supportedPresetSources并未登记 forgejo 对应的 Tags 数据源因此forgejoxxx形式的 Preset 在本管理器中会被归入unsupported-datasource处理。未固定版本则跳过若parsedPreset.tag为空如githubabc/foo、gitlababc/bar:xyz依赖以skipReason: unspecified-version记录——这正是 README 中“不会为未固定版本的 Preset 创建固定”的源码实现对应测试 extract.spec.ts。已固定版本则提取为依赖生成{ depName: repo, datasource, currentValue: tag }后续由对应的 tags 数据源发现新 Tag 并发起更新。githubabc/bar:xyz#1.2.3、githubcde/foo//path/xyz#1.2.3、githubcde/bar:xyz/sub#1.2.3等“预设名 / 子目录 / 嵌套预设名”写法均能被正确解析出仓库名与 Tagextract.spec.ts 分别对 GitHub、GitLab、Gitea 三种来源给出了完整断言。不受支持的 Preset 形式官方文档列出的 Unsupported Configreadme.md与源码行为一一对应不受支持的形式说明源码中的处理结果Local Presetslocalpath引用本地文件skipReason: unsupported-datasourceHTTP URL Presets从任意 HTTP 服务器拉取skipReason: unsupported-datasourcepackage.json中的 Renovate 配置已弃用managerFilePatterns显式排除package.json文件本身不被本管理器扫描npm 托管 Presets已弃用skipReason: unsupported-datasource子对象内的extends如packageRules里无法静态定位版本schema 不提取、无版本可固定相对路径 Preset./x、../x、/x没有独立仓库可跟踪skipReason: unsupported-datasource测试见 extract.spec.ts需要强调skipReason条目只是让诊断信息更完整便于在日志/仪表盘中看到“为何某 Preset 不被更新”并不会触发任何更新动作。Tool constraints把工具版本也当成依赖官方行为说明README 的另一半内容是Tool constraintsRenovate 会提取并建议更新constraints配置中的包管理器/工具版本。“对 Containerbase 支持的工具设置的约束会触发 Renovate 更新其他约束则不会。”一个综合示例取自 测试用例可直接作为实战参考{ extends: [ githubabc/foo#1.2.3 ], constraints: { bazelisk: 1.2.3, maven: 4.0.0 } }constraints支持精确版本golang: 1.20.5与范围版本 1.2.3、 4.0.0并且可以下沉到packageRules做按文件分组约束{ constraints: { golang: 1.20.5 }, packageRules: [ { matchFileNames: [go.mod], constraints: { golang: 1.26.0, gomodMod: 1.2.0 } } ] }源码印证工具名的识别与依赖生成约束的提取逻辑在 extract.ts对constraints以及每条packageRules[].constraints的每个键值对先用isToolName判断键是否为受支持工具名是工具名从 allToolConfig 取出该工具的datasource/packageName/versioningextractVersion可选生成依赖时附带depType: tool-constraint与commitMessageTopic: {{{depName}}} tool constraint从而让 PR 标题使用“xxx tool constraint”这一措辞与依赖更新区分开。例如测试断言了bazelisk: 1.2.3会解析为datasource: github-releases、packageName: bazelbuild/bazelisk、versioning: semverextract.spec.ts。不是工具名如gomodMod、go以skipReason: unsupported与depType: constraint记录不会产生更新——这正对应 README 的“Other constraints will not be updated by Renovate”。受支持的工具名清单是编译期常量toolDefinitionstypes.ts当前包含apm、bazelisk、bun、bundler、cocoapods、composer、conan、copier、corepack、deno、devbox、dotnet、erlang、elixir、flux、gh、gleam、golang、gradle、hashin、helm、helmfile、java、java-maven、jb、kustomize、maven、mise、nix、node、npm、pdm、php、pip-tools、pipenv、pnpm、pixi、poetry、python、ruby、rust、uv、yarn、yarn-slim、dart、flutter、vendir。每个工具在allToolConfig中声明了版本发现渠道可举几例工具datasourcepackageNameversioningbazeliskgithub-releasesbazelbuild/bazelisksemvermavengithub-releasescontainerbase/maven-prebuildmavengolanggithub-releasescontainerbase/golang-prebuildnpmpoetrypypipoetrypep440nodegithub-releasescontainerbase/node-prebuildnode除工具约束外types.ts还定义了additionalConstraintDefinitionstypes.ts如ghActionsLockgithub-actions 管理器的锁文件扩展、gomodModgomod 管理器的marwan-at-work/mod版本、jenkins、platform、rubygems、vscode、dotnet-sdk、perl、%goMod等。这些约束供各自管理器内部消费不属于renovate-config管理器会发起更新的工具在提取阶段统一标记unsupported。从配置到安装命令约束的下游消费提取出的工具约束最终服务于“动态安装”运行时通过 resolveConstraint 把约束精确或范围解析成具体版本——先用对应 versioning 校验约束合法性再用数据源返回的 releases 中匹配约束的最新稳定版本兜底逐级降级稳定匹配 → 不稳定匹配 → 最新稳定 → 最高版本并告警随后 generateInstallCommands 生成install-tool name version命令交给 Containerbase 执行。需要说明适用前提isDynamicInstall 表明动态安装仅在binarySource: install且运行于 Containerbase 环境检测到CONTAINERBASE环境变量时生效否则回退到binarySourceglobal。换句话说constraints的版本更新 PR 在任何部署形态下都会产生但“解析约束→安装指定版本”的完整链路主要在有 Containerbase 参与的场景中发挥作用。端到端验证一次提取的完整决策过程以 extract.spec.ts 的综合用例 为例extractPackageFile对如下输入{ extends: [ githubabc/foo#1.2.3, githubabc/bar:xyz#1.2.3, githubcde/foo//path/xyz#1.2.3, githubcde/bar:xyz/sub#1.2.3 ], constraints: { bazelisk: 1.2.3, maven: 4.0.0 } }会产出 6 条依赖4 条github-tags依赖depName分别为abc/foo、abc/bar、cde/foo、cde/barcurrentValue均为1.2.3注意预设名与子目录段都被剥离和 2 条tool-constraint依赖bazelisk→bazelbuild/bazelisk、maven→containerbase/maven-prebuild。若文件中只有draftPR: true之类无关字段则返回null整个管理器对该文件“无感”。实践要点小结想让 Preset 版本被 Renovate 维护必须使用github/gitlab/gitea前缀且带#tag固定版本local、HTTP URL、npm 托管与相对路径 Preset 一律不会更新。模板化 Preset含{{ ... }}在静态提取阶段被静默跳过属预期行为。constraints只更新工具约束键名必须在toolDefinitions清单内才会生成tool-constraint依赖gomodMod、go等附加约束属于各管理器内部机制不会被本管理器更新。诊断信息可查证各类skipReasoninvalid-value、unsupported-datasource、unspecified-version、unsupported均可在 skip-reason 类型定义 中找到配合日志即可定位“某条 Preset/约束为何没有更新 PR”。JSON5 友好renovate.json5支持注释与尾随逗号与标准 JSON 语义一致。核心源码入口一览管理器注册 index.ts、提取逻辑 extract.ts、配置模式 schema.ts、Preset 语法解析 parse.ts、工具清单与解析 containerbase.ts 与 types.ts、行为测试 extract.spec.ts。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考