Renovate 安装接入与配置校验

概述

作为 Dependabot 之外的另一套依赖治理方案，Renovate 更像“可高度编排的依赖自动化引擎”。本节从 GitHub App 安装接入讲起，说明为什么推荐把配置放在 .github/renovate.json5，如何用 config:recommended 最小起步，如何通过 Dashboard 或 CLI 校验配置，以及 silent 与 interactive 状态对是否创建 PR 的决定性影响，最后理解其节流与分组策略。

学习目标

• 理解 Renovate 与 Dependabot 定位不同，前者更灵活、更跨平台、更可编排。
• 掌握 Renovate 在 GitHub 上的接入顺序：安装 App、授权、选择仓库、启动 onboarding。
• 知道配置文件推荐放在 .github/renovate.json5，并用 config:recommended 最小起步。
• 会用 Dashboard 或 renovate-config-validator 校验配置。
• 理解 silent 与 interactive 状态差异，以及推荐配置下的节流策略。

一、Renovate 的定位：可编排的依赖引擎

上一节讲了 Dependabot，这一节讲另一条主流路线 Renovate。两者都能发现依赖更新、创建更新 PR，但 Renovate 的平台支持更广、配置更灵活。所以本节重点不再是“为什么要依赖自动更新”，而是 Renovate 怎么装、配置文件放哪、和 GitHub App 的关系、自动更新工作流怎么看。项目依赖治理已从“官方内置方案”扩展到了“更可编排、更跨平台”的方案层。

Renovate 不是 Dependabot 的简单替代品，而是能力边界不同的方案；对当前 GitHub 项目，它更偏进阶扩展，而不是起步默认值。

二、接入起点：安装 GitHub App

实操时，课程没有一开始就写配置文件，而是先打开 GitHub Marketplace 上的 Renovate 应用页，完成最关键的几步：点击安装、完成 GitHub 授权、选择要安装到哪些仓库。

这一步非常关键，因为 Renovate 在 GitHub 上首先是一个 GitHub App，只有安装并授权完成，它才有机会扫描仓库、创建 onboarding PR、执行后续更新任务。可以选择只装部分仓库，也可以选全部仓库。没完成安装授权前，配置文件写得再好也不会生效。

Renovate GitHub 接入顺序：
  Marketplace 安装
  GitHub 授权
  选择仓库
  启动 onboarding

三、配置文件放在 .github/renovate.json5

很多简化教程会说在仓库根目录建 renovate.json，但官方推荐做法是 .github/renovate.json5。这体现两个层面的工程意识：一是位置更规范，跟 .github/workflows/ 一样收拢在 GitHub 生态相关配置处；二是 json5 支持注释，对复杂配置可读性和维护性更好。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  extends: ["config:recommended"],
}

配置文件本身是要长期维护的，不是一次性随便糊过去。json5 支持注释的价值正在于此。

四、最小可用配置：config:recommended

官方其实鼓励你先站在默认推荐配置之上，再逐步扩展自己的规则，不要求一开始就把几十个选项全写出来。最稳的起点就是 config:recommended。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  extends: ["config:recommended"],
  baseBranches: ["main"],
}

不要一开始就试图把 Renovate 所有选项配完；config:recommended 提供一套官方建议的默认组合。课程专门回到官方文档确认这一点，本质是在避免被过时示例误导。

五、配置校验：Dashboard 与 CLI 两条路

写完 renovate.json5 后，下一步不是盲等它生效，而是先做配置校验。两种方式：去 Renovate 网页端 / 开发者后台看当前配置有没有报错；或本地装 CLI 用 renovate-config-validator 校验。

renovate-config-validator

对于 GitHub App 用户，Dashboard 更直观——能直接看到仓库状态、报错原因、是否进入静默模式。写完配置文件先校验，是所有机器人配置的基本动作；配置一旦错了，后面只会盲等。

六、silent 与 interactive：决定会不会创建 PR

在后台页面上会看到一个关键状态：仓库当前是 silent。这个状态的影响是：Renovate 会跑，但不会去创建 PR 或 Issue。这很容易让人误判成“配置没生效”或“安装没成功”。所以要先把 silent 调成 interactive，再 Run Renovate，才会开始产出 PR 和依赖更新结果。

切到 interactive 并手动触发后，Renovate 会创建更新 PR，也会生成额外的 issue / dashboard（如 Dependency Dashboard）。但项目里可更新依赖很多，初次可能只出现少量 PR——这往往不是配置错了，而是推荐配置里带有限流和分组策略在生效。Renovate 更强调“有节制地产生更新 PR”，帮你控制更新洪水。

Renovate 仓库状态：
  silent       -> 跑但不发 PR
  interactive  -> 正常创建 PR / Issue

七、从最小配置走向贴近项目的规则：分组、节奏与自动合并

config:recommended 只是起点，真正落地时通常会继续加规则。课程里提到，可在最小配置上扩展出更贴近项目的策略：

• 为 patch / minor / major 设不同分组，避免更新 PR 混在一起；
• 用 schedule 限定扫描与建 PR 的时间窗口，减少打扰；
• 对低风险更新开 automerge，让补丁级更新自动合入。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  extends: ["config:recommended"],
  baseBranches: ["main"],
  packageRules: [
    { "matchUpdateTypes": ["patch"], "groupName": "patch-updates", "automerge": true },
    { "matchUpdateTypes": ["minor"], "groupName": "minor-updates" },
  ],
}

这些规则的价值在于把“更新噪音”和“可控性”重新交回团队手里。对比 Dependabot，Renovate 在 PR 分组、节奏和自动合并上的可编排性，正是它更适合复杂跨平台项目的核心原因。

常见问题

延伸阅读

• 上一篇：Dependabot 依赖更新与 Renovate 方案对比
• 下一篇：Vite 库模式与 Playground 验证
• 相关：Renovate 安装与 Onboarding、Renovate 配置文档、Renovate JSON Schema、Renovate 阅读清单