Renovate 安装与仓库 Onboarding 全指南从 GitHub App 安装到 Configure Renovate 配置合并【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本篇指南围绕 Renovate CLI 的核心接入流程展开如何将 Renovate 安装到目标仓库、如何理解并处理 Configure Renovate onboarding Pull Request、以及仓库上线后如何安全地二次调整配置。读完本文你将掌握 GitHub/GitLab 托管 App 安装、自托管 Windows 注意事项、配置文件位置与命名规则、常用覆盖项如rangeStrategy、labels的实战用法以及 通过 PR 重配 与 删配置重新 onboarding 两种仓库重配路径并了解这些行为在 Renovate 源码lib/workers/repository/onboarding中的底层实现依据。关于安装 Renovate 的安全与隐私在把 Renovate 接入仓库之前建议先阅读 Security and Permissions 页面该文档系统说明了Renovate 的安全立场security stance与权限模型当组织要求使用经过认证的软件时应当如何处理安全问题的披露流程security/disclosure processRenovate 申请的各类平台权限及隐私处理方式。这些信息决定了是否允许 Renovate 访问全部仓库这一关键决策建议在安装前完成评估。仓库级安装Repository installationRenovate 管理员有两种方式决定 Renovate 运行在哪些仓库上autodiscover自动发现将全局配置autodiscover设为trueRenovate 会在所有被授予访问权限的仓库上运行固定仓库列表在全局配置中显式列出仓库名此时新增仓库只能由管理员手动加入列表待下一次运行或重启后生效。一旦采用固定列表模式用户侧没有自助安装的入口需要管理员介入。其余场景下将新仓库加入 Renovate 安装的常见方式有最常见的做法是使用专用账号运行 Renovate并开启全局autodiscover: true让 Renovate 自动覆盖所有已授权仓库如果使用 GitHub App包括 Mend Renovate App可以把它安装到某个用户或组织账号下然后选择 All repositories全部仓库或 Select repositories手动挑选仓库。Hosted GitHub.com App安装 Mend Renovate App 的步骤如下在 GitHub 上进入 Renovate 的 App 页面Mend 出品点击绿色的Install按钮在安装页面只需做一个选择让 Renovate 运行在所有仓库还是选定的仓库上关于仓库选择有几个值得注意的行为Renovate 会自动忽略不含已知包管理器文件的仓库也会忽略 fork 仓库因此即使选择全部仓库也不会产生噪音尽管如此大多数用户仍倾向使用选定仓库模式GitHub 不提供除 X、Y、Z 外全部选择的逆向选项所以选择模式下需要逐个勾选目标仓库完成选择后点击页面底部的绿色Install按钮Renovate 即对该仓库生效并启动 onboarding 流程。[!NOTE] Mend Renovate App 对 fork 仓库有特殊行为选择 All repositories 安装时fork 仓库默认会被跳过而选择 Select repositories 安装时即便目标是 forkRenovate 也会处理。该行为与源码中forkProcessing的默认值auto即 autodiscover 模式下默认跳过 fork保持一致见 lib/config/options/index.ts。Hosted GitLab.com AppMend 于 2026 年 7 月基于比旧版更安全的架构重新发布了 GitLab.com 托管 Renovate App。设置方式登录 Mend Developer Platform 后按其官方集成文档的指引完成安装。当前约束与计划目前仅支持安装在 GitLab.com 的 Group群组上计划支持 User个人级安装但暂无明确时间表。自托管在 Windows 上在 Windows 上自托管 Renovate 时推荐在 Git 配置中设置core.autocrlf inputgit config --global core.autocrlf input这样可避免 Windows 行尾的\r\n回车符干扰 Renovate 对文件内容的解析。另一种做法是在仓库中通过.gitattributes固定行尾* textauto eollf仓库 OnboardingConfigure Renovate PR当 Renovate 在某个仓库上被启用后它会创建一个名为 Configure Renovate 的 Pull Request形如下方截图[!NOTE] 自托管用户若希望在 onboarding PR 中加入 rebase/retry 复选框需要先在全局配置中开启onboardingRebaseCheckbox选项。该选项为实验特性默认false仅支持 forgejo、gitea、github、gitlab 平台参见 lib/config/options/index.ts。零风险 onboardingNo risk onboardingonboarding 流程被刻意设计为零风险在你合并onboarding PR 之前Renovate 不会对仓库做任何改动也不会提出任何其他 Pull Request。如果对 PR 内容有疑问可以先去 使用文档首页 查阅资料也可以在 GitHub Discussions 论坛提问确认满意后再合并你可以在renovate/configure分支内直接编辑 Renovate 配置Renovate 会持续更新 PR 描述与之同步——这意味着可以反复迭代配置直到结果符合预期如果想退出直接关闭不合并onboarding PR 即可且该操作可逆——把已关闭的 onboarding PR 重命名即可重新触发 onboarding PR或者直接向默认分支提交一个 Renovate 配置文件实现手动 onboarding。从源码看未合并则不动仓库由 lib/workers/repository/onboarding/branch/check.ts 中的isOnboarded()逻辑保障只有检测到已存在配置文件、已合并配置、或处于 silent 模式等情况下才认为仓库已 onboard否则持续停留在 onboarding 阶段不会进入常规更新流程。检查 Warnings 警告在 onboarding PR 中若出现 Warnings 或 Errors 列表请评估是否需要修复警告与错误应修复在基础分支如main上这样 Renovate 在下一个运行周期才能基于修复后的状态重建 Configure Renovate PR修复动作本身不需要合并 onboarding PR属于前置条件处理。配置文件位置Configuration locationConfigure Renovate PR 默认会在仓库根目录生成一个renovate.json内含建议的默认设置。如果不想在根目录放renovate.json可使用以下任一文件代替renovate.json5.github/renovate.json.github/renovate.json5.gitlab/renovate.json.gitlab/renovate.json5.renovaterc.renovaterc.json.renovaterc.json5package.json已弃用也可以使用configFileNames指定的自定义文件名。Renovate 会先检查configFileNames数组中的全部文件再检查上面这份默认文件列表。这一查找顺序在源码中有精确对应默认文件模式定义在 lib/config/app-strings.ts 的configFilePatterns中getConfigFileNames()会按平台过滤例如.gitlab/renovate.json只在 GitLab 平台生效其他平台还会追加.{platform}/renovate.json{,c,5}模式并把用户自定义的configFileNames放在最前参见 lib/config/app-strings.ts。onboarding 检测同样复用该函数逐个探测文件是否存在且会跳过package.json单独校验其中的renovate字段见 lib/workers/repository/onboarding/branch/check.ts。package.json已弃用[!WARNING] 在package.json中放置 Renovate 配置的方式已被弃用将在未来版本移除。将配置写入仓库根目录package.json的renovate字段即可生效package.json必须位于仓库根目录该方式适合本身就在使用package.json的 JavaScript 项目package.json中的配置作用于整个项目包括其它嵌套的package.json。自定义默认值Customized defaultsRenovate 默认提供的renovate.json适用于大多数场景。有时 Renovate 会检测到需要覆盖默认值并自动补充典型例子若仓库本身使用 Angular 风格语义化提交semantic commitsRenovate 会自动启用对应的语义提交配置根据检测到的项目类型应用 app 还是库 library自动决定是否使用依赖版本范围固定dependency range pinning。常见覆盖项Common overrides完整配置项请查阅官方 Configuration Reference以下是最常被改写的几个设置配置项说明rangeStrategy默认零配置为replace但config:recommended预设会将其覆盖为auto也有用户偏好bumplabels为 Pull Request 分配的标签assignees被指派处理 Pull Request 的 GitHub 用户Renovate 每次发现变更都会更新 PR 描述。合并Merge当你在 Configure Renovate PR 中完成检查与配置后合并它即真正开启后续依赖更新 PR 的生成。仓库重新配置Repository re-configuration仓库上线后仍需调整配置时有两种推荐方式。方式一通过 PR 重配置Reconfigure via PR新建名为renovate/reconfigure的分支编辑 Renovate 配置文件从该分支发起 Pull Request在仓库上运行 Renovate自托管或等待托管 App 处理变更Renovate 会在 PR 上评论概述新配置将带来的预期变更可以在同一 PR 内继续编辑配置文件Renovate 会同步更新评论内容若只想校验配置合法性而不触发更新可参考 Validate your config 使用配置校验能力。方式二删除配置重新 onboardingNuke config and re-onboard如果你喜欢交互式 onboarding PR 并想再来一次可以核弹式重置找到最初的Configure RenovatePR将其重命名为其他名称例如Configure Renovate - old从主分支删除当前的 Renovate 配置文件如renovate.json。完成上述步骤后Renovate 会认为该仓库从未 onboarding 过从而触发一个新的 Configure Renovate PR此前的所有 Renovate PR 也会随之被关闭。若使用 Mend Renovate App 且数小时内未收到新的 onboarding PR可在 Discussions 发帖请求工作人员手动触发。从实现上看isOnboarded()会通过closedPrExists()检查已关闭的 onboarding PR 并据此判断仓库状态同时onboardingAutoCloseAge等机制会对关闭过久的 onboarding PR 自动评论说明恢复方式参见 lib/workers/repository/onboarding/branch/check.ts。这与重命名已关闭 PR 即可重新 onboarding的交互完全对应。源码视角onboarding 相关的关键配置项围绕 onboarding 流程仓库中定义了多个全局globalOnly配置项汇总如下便于自托管管理员按需调整均见 lib/config/options/index.ts配置项默认值说明源码位置onboardingConfigFileNamerenovate.jsononboarding 生成的配置文件名称index.ts#L305-L313onboardingPrTitleConfigure Renovateonboarding PR 标题index.ts#L324-L332onboardingCommitMessagenull覆盖 onboarding 提交信息index.ts#L285-L294onboardingNoDepsauto未发现依赖时是否仍创建 onboarding PRauto/enabled/disabledindex.ts#L314-L322onboardingConfig{ $schema: ... }onboarding PR 使用的配置内容可合并index.ts#L756-L765onboardingRebaseCheckboxfalse是否在 onboarding PR 中启用 rebase/retry 复选框实验特性index.ts#L767-L776configFileNamesnull仓库配置文件名列表全局、可继承index.ts#L296-L303forkProcessingautoautodiscover 模式下对 fork 仓库的处理策略index.ts#L778-L785另外默认 onboarding 配置的生成还有一个组织预设优先逻辑Renovate 会依次探测localgroup/renovate-config或org/.{platform}:renovate-config这类组织级默认预设存在则以其extends生成 onboarding 配置否则回退到默认配置参见 lib/workers/repository/onboarding/branch/config.ts。这意味着组织可以提前维护一份统一的 Renovate 预设让所有新仓库的 onboarding PR 自动继承组织规范。小结Renovate 的接入遵循一条清晰的路径先通过autodiscover或固定列表含 GitHub/GitLab 托管 App完成安装再经由零风险的 Configure Renovate onboarding PR 完成配置确认最后按需通过renovate/reconfigurePR 或删除配置重新 onboarding 实现持续演进。理解配置文件探测顺序configFileNames优先于默认列表、fork 处理策略与组织预设机制能帮助你在自托管场景下更精准地控制每个仓库的接入行为。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考