4.1 KiB
Agent Note: Dependabot 版本更新采用 30 天冷却期
Status: implemented
English | 中文
问题
来自包注册表的依赖与 GitHub Actions 依赖都需要定期更新机制。每个新版本一经发布便立即采用，会增加受到遭入侵的版本和早期回归影响的风险；但完全依靠手动更新，又会导致依赖版本差距持续扩大。以源码形式纳入仓库的 Cordis 与各自维护独立锁文件的工作区，也不能不加区分地视为同一棵包树。
决策
默认分支包含 .github/dependabot.yml，其中为根 pnpm 工作区、独立维护锁文件的 native/landlock-run pnpm 工作区、python/sdk uv 项目和 GitHub Actions 配置了每周一次的版本更新检查。每个更新项都将 cooldown.default-days 设为 30，因此某个版本只有在发布至少 30 天后才符合更新条件，并会在下一次每周检查时生成更新提案。
根 pnpm 工作区的版本更新扫描排除 vendor/**，其中的源码和 manifest（元数据清单）只能通过 vendoring 流程变更；扫描还排除由专用更新项负责的 native/landlock-run/**。GitHub 仅将 exclude-paths 用于版本更新；如果安全更新 PR（Pull Request）涉及随源码纳入仓库的 manifest，则改由 vendoring 流程处理，以替代自动生成的 PR，而不会将其原样合并。Dependabot PR 会获得仓库的 cleanup 类型标签和 area/infra 区域标签，运行常规 PR 检查，并且仍须由维护者评审；该自动化不会合并这些 PR。
仓库设置已启用依赖项漏洞警报和 Dependabot 安全更新。GitHub 不会对这些安全更新应用版本更新冷却期，因此安全修复仍可立即进入更新流程。如果依赖解析还选中了其他刚发布的传递依赖，pnpm 安全更新 PR 仍可能无法通过仓库的锁文件发布时长校验；此类 PR 应等待隔离期结束或缩小更新范围，不得因此放宽政策。仓库为协调刚发布版本而设置的例外，不会纳入 Dependabot 的冷却期排除项：自动版本更新统一等待 30 天；经过明确评审的手动更新仍可遵循相应的发布流程。
pnpm 更新项让两个工作区继续使用已固定的 pnpm 11，不会仅为了自动化而降级版本。当前 Dependabot 更新器会安装 packageManager 指定的版本，并读取两个工作区使用的 9.0 锁文件格式；由提供方运行的更新任务仍作为集成检查。
考虑过的替代方案
- 立即进行版本更新。 不采用，因为这会取消所要求的版本发布后隔离期，使项目在每个上游版本的发布初期就采用该版本。
- CI 通过后自动合并。 不采用，因为依赖变更可能改变运行时、构建和发布行为；是否接受更新仍须经过常规评审决策。
- 使用一次递归 npm 扫描。 不采用，因为它可能将随源码纳入仓库的 manifest 纳入更新范围，或混淆根工作区与 native 工作区的锁文件。显式排除项和专用 native 更新项可维持各自的归属边界。
- Renovate 或定期运行的 agent（智能体）。 二者都能为发布已满一定时长的版本提出更新，但所要求的服务是 Dependabot，而且仓库 CI 已将其 PR 视为不可信的依赖来源。
- 为需协调的刚发布版本设置冷却期豁免。 自动化路径不采用，因为此类版本需要明确的同步决策或模型目录决策，不能由通用更新提案代替。
后果
- 隔离期结束后，常规依赖更新会以规模较小、便于评审的 PR 形式到达，无需维护者定期手动发现更新。
- 由于每周评估一次更新资格，相应更新 PR 通常会在版本发布后 30 至 36 天出现。
- Dependabot 不会延迟安全更新提案；仓库检查仍可阻止无关的刚发布传递依赖，评审流程也会维持 vendoring 边界。
- 维护者仍负责决定是否合并每项更新，并诊断 pnpm 11 更新任务报告的任何提供方限制。