概述
依赖自动化失败的常见原因是它制造的工作量超过节省的工作量。每周二十个独立 PR 通常会被忽略或盲目合并。先分组:非主版本的开发依赖可以共用一个 PR,因为它们通常一起测试且很少影响生产运行时;运行时依赖按生态或关键性分组,不要把 linter 和数据库驱动混在一个巨大 PR 里。再用 prConcurrentLimit 和 prHourlyLimit 限制并发与每小时数量,并安排固定评审窗口。安全漏洞告警应绕过常规日程立即处理。
步骤
在仓库根目录添加 renovate.json,继承推荐配置和依赖面板,设置每周计划与分组规则:
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:recommended", ":dependencyDashboard", ":semanticCommits"],
"schedule": ["before 6am on Monday"],
"prConcurrentLimit": 4,
"prHourlyLimit": 2,
"packageRules": [
{
"matchDepTypes": ["devDependencies"],
"matchUpdateTypes": ["minor", "patch"],
"groupName": "dev dependencies (non-major)"
},
{
"matchUpdateTypes": ["patch"],
"matchCurrentVersion": ">=1.0.0",
"automerge": true,
"automergeType": "pr",
"platformAutomerge": true
},
{
"matchManagers": ["github-actions"],
"pinDigests": true
},
{
"matchUpdateTypes": ["major"],
"dependencyDashboardApproval": true
}
],
"vulnerabilityAlerts": { "enabled": true, "labels": ["security"] },
"osvVulnerabilityAlerts": true
}
本地校验:
npx --yes --package renovate renovate-config-validator renovate.json
提交到分支并创建 PR 后合并。等待 Renovate 首次运行,用 gh issue list --search "Dependency Dashboard in:title" 确认依赖面板已创建。再用 gh pr list --label dependencies 查看分组 PR;对 GitHub Actions 的更新,检查 diff 中的 uses: 是否变成 40 位 commit SHA,而不是可变 tag。
验证
逐条查看依赖 PR 的 auto-merge 与检查状态:
gh pr list --label dependencies --json number --jq '.[].number' | while read -r pr; do
gh pr view "$pr" --json number,title,autoMergeRequest,statusCheckRollup \
--jq '{number, title, autoMerge: (.autoMergeRequest != null), checks: [.statusCheckRollup[]?.conclusion]}'
done
至少应有一个候选 PR 显示 autoMerge: true 且检查为 SUCCESS;主版本更新应出现在依赖面板等待人工批准,而不是直接开 PR。
注意事项
自动合并只应覆盖主版本之外、且有可靠测试的更新;补丁版本仍可能破坏 CI 未覆盖的行为。pinDigests 只对 github-actions manager 生效,本地 composite action 不会被固定。私有 registry 需要 hostRules 和密钥,不要把凭据写进 renovate.json。计划使用 UTC,托管运行器可能晚于名义窗口执行。依赖面板不能成为唯一查看入口,安全 PR 失败要进入与事故相同的通知渠道。