尧图网站建设 
如何创建并让其他仓库 extends 你的 Renovate 共享配置预设【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate当你用 Renovate 管理多个仓库时把相同的 Renovate 配置复制进每个仓库的renovate.json很快会变成重复劳动改一处规则就要挨个仓库改。Renovate 的共享配置预设Shareable Config Presets解决的就是这个问题把配置集中放到一个独立的预设仓库里其他仓库在自己的extends数组里引用它之后只需修改预设仓库这一个文件。本文覆盖从创建预设仓库、组织预设文件、让其他仓库extends它到验证预设可被正确解析的完整路径。适用前提预设文件必须是 JSON、JSONC 或 JSON5 格式其他格式不支持预设仓库通常部署在 Renovate 所运行的那个平台主机上GitHub、GitLab、Gitea、Forgejo或自托管 Git。创建预设仓库并写入预设文件按 Shareable Config Presets 的说明托管一个预设只需要一个 Git 仓库和若干 JSON 文件创建一个新仓库。习惯上命名为renovate-config但名字可以任意。在仓库中添加预设文件默认预设default.json。引用时省略文件名如githubabc/fooRenovate 就去找default.json。命名预设preset-name.json。例如加载预设library会读取library.json。除预设文件外不需要其他文件——文档明确说明你不需要把它加为 devDependency 或添加任何其他文件。仓库根目录放一个default.json的示例extends中的预设名来自文档示例{ extends: [config:recommended, schedule:nonOfficeHours] }建议用description字段描述预设的作用或者直接在文件里写注释——预设文件支持 JSONC 语法。预设仓库支持用 Git tag 锁定版本tag 可以是 SemVer 形式的发布号。如果你希望消费方固定使用某个版本而不是跟随默认分支在推送时打上 tag消费方用#tag语法引用即可见下文。在其他仓库中用 extends 引用预设消费方只需要在renovate.json或其他 Renovate 配置文件的extends数组里写入预设位置字符串。预设可以嵌套extends数组里可以放多个预设发生逻辑冲突时数组中最后一个预设生效。GitHub 上的常用引用形式其余平台的表结构相同只需替换前缀引用写法解析结果读取的文件Git taggithubabc/foo仓库默认预设default.json默认分支githubabc/foo:xyz命名预设xyzxyz.json默认分支githubabc/foo//path/xyz路径下预设path/xyz.json默认分支githubabc/foo#1.2.3默认预设default.json1.2.3githubabc/foo:xyz#1.2.3命名预设xyz.json1.2.3命名预设也可以带扩展名如githubabc/foo:xyz.jsonc、githubabc/foo:xyz.json5对应读取xyz.jsonc/xyz.json5。GitLabgitlabowner/name、Giteagiteaowner/name、Forgejoforgejoowner/name的写法与 GitHub 完全对应。:前缀的:xyz命名惯例指内置的default:预设:xyz等价于default:xyz与仓库托管预设无关。自托管平台的local前缀如果 Renovate 运行在自托管平台例如 GitHub Enterprise Server 实例用local从当前 Git 服务器查找预设在github.com上运行时local等价于github。因为local跟随当前平台解析跨平台迁移仓库时预设引用不用改写文档推荐用它来保持可移植性。例如{ extends: [localrenovate/presets] }不带前缀的owner/name也按当前平台解析效果等同localowner/name。在预设仓库内组织多个文件相对引用一个预设仓库可以包含多个预设文件文件之间用相对路径互相引用。Renovate 会把相对引用解析到引用它的预设所在的来源仓库和 tag 上因此移动、fork 预设仓库或给它打 tag 时文件内部的引用不需要改动。语法相对位置./x含引用的预设文件所在目录../x上一级目录/x预设仓库根目录文档给出的布局示例default.json system/registries.json security/base.jsondefault.json中这样引用另外两个文件{ extends: [./system/registries, /security/base] }此时如果某个仓库 extendsgithuborg/repo#v2.0.0这两条引用会被解析为githuborg/repo//system/registries#v2.0.0和githuborg/repo//security/base#v2.0.0——tag 从外层预设继承所有文件都从同一个 tag 读取。相对引用的使用限制preset 作者需要遵守相对引用只能在预设内部使用。仓库自己的renovate.json、继承配置或globalExtends中不接受相对引用相对引用不能附加#tagtag 总是继承自引用方预设相对引用指向的是预设文件不能像//path语法那样指向文件内的子预设键路径中含 Handlebars 模板如./{{ env.SOME_VAR }}/base的引用不会被改写会解析失败。一个值得注意的坑renovate-config-validator在任何文件里都接受相对引用所以仓库自身配置中误写相对引用时验证工具能过只有 Renovate 实际运行时才会失败。相对引用无法解析例如逃出仓库根目录会导致所有 extends 该预设的仓库报配置错误所以下一节的验证步骤是 preset 作者流程的一部分而不是可选操作。验证预设仓库文档建议在 CI 中验证预设仓库官方给出的工具是renovate-config-validator每个renovate发行版都包含该程序见 Config Validation。关键细节当你以 CLI 参数指定文件名时validator 会把该文件当作全局自托管配置来校验对共享预设文件必须加--no-global将其按仓库级配置处理$ npx --yes --package renovate -- renovate-config-validator --no-global default.json INFO: Validating default.json INFO: Config validated successfully仓库中有多个预设文件时对每个文件各跑一次即可。在消费方仓库侧还有第二条验证路径如果 Renovate 正在运行于该仓库把修改后的配置提交到匹配{{branchPrefix}}reconfigure模式的分支默认前缀renovate/即分支名renovate/reconfigure并推送。Renovate 下次运行时会对该分支添加通过/失败的状态检查如果有一个来自 reconfigure 分支的开放PRRenovate 还会在 PR 里评论校验错误详情并在 PR 合并前对每个新 commit 重新验证。注意该分支必须推送到 Renovate 运行的源仓库不能推到 fork。如果想确认一次运行中实际合并了哪些预设文档给出的方法是以LOG_LEVELdebug运行 Renovate查看Resolved shallow config, without merging internal presets消息中的visitedPresets字段它以绝对形式列出每个被合并的预设。版本固定与消费方排除预设tag 固定消费方写githubabc/foo:xyz#1.2.3后所有从该预设仓库读取的文件都来自1.2.3这个 tag。预设发布新版本后消费方显式改 tag 才升级。排除预设消费方可以用ignorePresets跳过预设链中的某个文件但必须写解析后的绝对形式含继承的 tag相对形式无效因为ignorePresets匹配的是已解析的预设字符串。例如跳过上文示例中的security/base.json{ extends: [githuborg/repo#v2.0.0], ignorePresets: [githuborg/repo//security/base#v2.0.0] }预设自身也可以在自己的ignorePresets里用相对形式排除自己引入的预设但 Renovate 在仓库配置存在ignorePresets时只使用仓库的那一份所以仓库一旦设置了ignorePresets预设内置的排除规则就不再生效。可选分支与限制以下路径文档均有说明按需取用HTTP 服务器托管目标平台尚未支持、或需要在--platformlocal下工作时extends可直接写 HTTP URL例如http://my.server/users/me/repos/renovate-presets/raw/default.json?atrefs%2Fheads%2Fmain。注意自托管 Renovate 默认会对内网地址回环、私有网段的 HTTP 请求告警需要管理员在自身配置的hostRules中显式设置allowInternaltrue配合hostType或matchHost限定范围才允许从内网主机拉取预设。组织级预设仓库 onboarding 时Renovate 会检查父级 user/group/org 下名为renovate-config且含default.json的仓库支持嵌套分组的平台如 GitLab会由近及远逐级查找并使用找到的第一个。若找到该预设会被作为唯一的 extends 建议已有的onboardingConfig会被忽略/覆盖。npm 托管预设已废弃文档明确不推荐使用npm:形式的预设计划在后续大版本移除同一文档也废弃了以renovate.json作为仓库默认预设文件名——如果你在用它分享预设应改名为default.json。路径与子预设语法不能组合providerowner/repo//path/to/file:subsubpreset这种形式不受支持需要用不同文件代替子预设。预设如果被认为对多数用户有价值还可以走文档 Contributing to presets 一节描述的流程提交给 Renovate 内置预设目录。创建、引用与验证的完整细节以 Shareable Config Presets 和 Presets 概念页 为准。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何创建并让其他仓库 extends 你的 Renovate 共享配置预设
如何创建并让其他仓库 extends 你的 Renovate 共享配置预设【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate当你用 Renovate 管理多个仓库时把相同的 Renovate 配置复制进每个仓库的renovate.json很快会变成重复劳动改一处规则就要挨个仓库改。Renovate 的共享配置预设Shareable Config Presets解决的就是这个问题把配置集中放到一个独立的预设仓库里其他仓库在自己的extends数组里引用它之后只需修改预设仓库这一个文件。本文覆盖从创建预设仓库、组织预设文件、让其他仓库extends它到验证预设可被正确解析的完整路径。适用前提预设文件必须是 JSON、JSONC 或 JSON5 格式其他格式不支持预设仓库通常部署在 Renovate 所运行的那个平台主机上GitHub、GitLab、Gitea、Forgejo或自托管 Git。创建预设仓库并写入预设文件按 Shareable Config Presets 的说明托管一个预设只需要一个 Git 仓库和若干 JSON 文件创建一个新仓库。习惯上命名为renovate-config但名字可以任意。在仓库中添加预设文件默认预设default.json。引用时省略文件名如githubabc/fooRenovate 就去找default.json。命名预设preset-name.json。例如加载预设library会读取library.json。除预设文件外不需要其他文件——文档明确说明你不需要把它加为 devDependency 或添加任何其他文件。仓库根目录放一个default.json的示例extends中的预设名来自文档示例{ extends: [config:recommended, schedule:nonOfficeHours] }建议用description字段描述预设的作用或者直接在文件里写注释——预设文件支持 JSONC 语法。预设仓库支持用 Git tag 锁定版本tag 可以是 SemVer 形式的发布号。如果你希望消费方固定使用某个版本而不是跟随默认分支在推送时打上 tag消费方用#tag语法引用即可见下文。在其他仓库中用 extends 引用预设消费方只需要在renovate.json或其他 Renovate 配置文件的extends数组里写入预设位置字符串。预设可以嵌套extends数组里可以放多个预设发生逻辑冲突时数组中最后一个预设生效。GitHub 上的常用引用形式其余平台的表结构相同只需替换前缀引用写法解析结果读取的文件Git taggithubabc/foo仓库默认预设default.json默认分支githubabc/foo:xyz命名预设xyzxyz.json默认分支githubabc/foo//path/xyz路径下预设path/xyz.json默认分支githubabc/foo#1.2.3默认预设default.json1.2.3githubabc/foo:xyz#1.2.3命名预设xyz.json1.2.3命名预设也可以带扩展名如githubabc/foo:xyz.jsonc、githubabc/foo:xyz.json5对应读取xyz.jsonc/xyz.json5。GitLabgitlabowner/name、Giteagiteaowner/name、Forgejoforgejoowner/name的写法与 GitHub 完全对应。:前缀的:xyz命名惯例指内置的default:预设:xyz等价于default:xyz与仓库托管预设无关。自托管平台的local前缀如果 Renovate 运行在自托管平台例如 GitHub Enterprise Server 实例用local从当前 Git 服务器查找预设在github.com上运行时local等价于github。因为local跟随当前平台解析跨平台迁移仓库时预设引用不用改写文档推荐用它来保持可移植性。例如{ extends: [localrenovate/presets] }不带前缀的owner/name也按当前平台解析效果等同localowner/name。在预设仓库内组织多个文件相对引用一个预设仓库可以包含多个预设文件文件之间用相对路径互相引用。Renovate 会把相对引用解析到引用它的预设所在的来源仓库和 tag 上因此移动、fork 预设仓库或给它打 tag 时文件内部的引用不需要改动。语法相对位置./x含引用的预设文件所在目录../x上一级目录/x预设仓库根目录文档给出的布局示例default.json system/registries.json security/base.jsondefault.json中这样引用另外两个文件{ extends: [./system/registries, /security/base] }此时如果某个仓库 extendsgithuborg/repo#v2.0.0这两条引用会被解析为githuborg/repo//system/registries#v2.0.0和githuborg/repo//security/base#v2.0.0——tag 从外层预设继承所有文件都从同一个 tag 读取。相对引用的使用限制preset 作者需要遵守相对引用只能在预设内部使用。仓库自己的renovate.json、继承配置或globalExtends中不接受相对引用相对引用不能附加#tagtag 总是继承自引用方预设相对引用指向的是预设文件不能像//path语法那样指向文件内的子预设键路径中含 Handlebars 模板如./{{ env.SOME_VAR }}/base的引用不会被改写会解析失败。一个值得注意的坑renovate-config-validator在任何文件里都接受相对引用所以仓库自身配置中误写相对引用时验证工具能过只有 Renovate 实际运行时才会失败。相对引用无法解析例如逃出仓库根目录会导致所有 extends 该预设的仓库报配置错误所以下一节的验证步骤是 preset 作者流程的一部分而不是可选操作。验证预设仓库文档建议在 CI 中验证预设仓库官方给出的工具是renovate-config-validator每个renovate发行版都包含该程序见 Config Validation。关键细节当你以 CLI 参数指定文件名时validator 会把该文件当作全局自托管配置来校验对共享预设文件必须加--no-global将其按仓库级配置处理$ npx --yes --package renovate -- renovate-config-validator --no-global default.json INFO: Validating default.json INFO: Config validated successfully仓库中有多个预设文件时对每个文件各跑一次即可。在消费方仓库侧还有第二条验证路径如果 Renovate 正在运行于该仓库把修改后的配置提交到匹配{{branchPrefix}}reconfigure模式的分支默认前缀renovate/即分支名renovate/reconfigure并推送。Renovate 下次运行时会对该分支添加通过/失败的状态检查如果有一个来自 reconfigure 分支的开放PRRenovate 还会在 PR 里评论校验错误详情并在 PR 合并前对每个新 commit 重新验证。注意该分支必须推送到 Renovate 运行的源仓库不能推到 fork。如果想确认一次运行中实际合并了哪些预设文档给出的方法是以LOG_LEVELdebug运行 Renovate查看Resolved shallow config, without merging internal presets消息中的visitedPresets字段它以绝对形式列出每个被合并的预设。版本固定与消费方排除预设tag 固定消费方写githubabc/foo:xyz#1.2.3后所有从该预设仓库读取的文件都来自1.2.3这个 tag。预设发布新版本后消费方显式改 tag 才升级。排除预设消费方可以用ignorePresets跳过预设链中的某个文件但必须写解析后的绝对形式含继承的 tag相对形式无效因为ignorePresets匹配的是已解析的预设字符串。例如跳过上文示例中的security/base.json{ extends: [githuborg/repo#v2.0.0], ignorePresets: [githuborg/repo//security/base#v2.0.0] }预设自身也可以在自己的ignorePresets里用相对形式排除自己引入的预设但 Renovate 在仓库配置存在ignorePresets时只使用仓库的那一份所以仓库一旦设置了ignorePresets预设内置的排除规则就不再生效。可选分支与限制以下路径文档均有说明按需取用HTTP 服务器托管目标平台尚未支持、或需要在--platformlocal下工作时extends可直接写 HTTP URL例如http://my.server/users/me/repos/renovate-presets/raw/default.json?atrefs%2Fheads%2Fmain。注意自托管 Renovate 默认会对内网地址回环、私有网段的 HTTP 请求告警需要管理员在自身配置的hostRules中显式设置allowInternaltrue配合hostType或matchHost限定范围才允许从内网主机拉取预设。组织级预设仓库 onboarding 时Renovate 会检查父级 user/group/org 下名为renovate-config且含default.json的仓库支持嵌套分组的平台如 GitLab会由近及远逐级查找并使用找到的第一个。若找到该预设会被作为唯一的 extends 建议已有的onboardingConfig会被忽略/覆盖。npm 托管预设已废弃文档明确不推荐使用npm:形式的预设计划在后续大版本移除同一文档也废弃了以renovate.json作为仓库默认预设文件名——如果你在用它分享预设应改名为default.json。路径与子预设语法不能组合providerowner/repo//path/to/file:subsubpreset这种形式不受支持需要用不同文件代替子预设。预设如果被认为对多数用户有价值还可以走文档 Contributing to presets 一节描述的流程提交给 Renovate 内置预设目录。创建、引用与验证的完整细节以 Shareable Config Presets 和 Presets 概念页 为准。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考