| name | review-pr |
| description | 当用户提到审核 PR、review PR、检查开放 PR、判断升级能否合并时使用。逐个读取 PR 信息与首个评论,提炼亮点更新和破坏更新,对照当前仓库/集群配置判断是否需要同步变更,并给出简洁结论与代码引用。 |
Review PR
目标
把每个 PR 压缩成一个可执行判断:
- 有哪些亮点更新
- 有没有破坏更新
- 当前配置要不要改
- 现在能不能合
默认按 一个个来 处理,等用户决定后再看下一个。
何时使用
出现以下意图时就使用:
- 审核 PR / review PR
- 检查开放 PR
- 看这个升级能不能合
- 合并前看下影响
- 看 breaking change
- 逐个过 Renovate PR
审查流程
1. 先读 PR 关键信息
每个 PR 至少检查:
首个评论优先级最高,通常最能说明升级范围和风险。
2. 明确升级信息
确认:
- 从什么版本到什么版本
- 升级的是镜像、应用、chart 还是 operator
- 影响的是哪个组件
如果 PR 里信息不够,按顺序补查:
- 上游 release notes
- changelog
- compare / tag 间提交摘要
只看发布说明和升级说明,不要分析上游源码。
3. 对照当前仓库配置
重点检查这些位置是否受影响:
k8s/apps/common/
k8s/infra/common/
k8s/components/
k8s/clusters/staging/
.renovate/packageRules.json5
以及相关资源:
HelmRelease
Kustomization
ExternalSecret
- values / 注解 / 参数 / CRD 用法
判断:
- 当前配置是否已兼容
- 是否需要先改配置再合并
- 是否只需合并后安排操作
- 是否应暂缓或直接关闭
审查重点
只关注和当前仓库/集群有关的变更,优先看这些:
配置结构变化
- 配置项改名
- 默认值变化
- 废弃字段删除
- 新增必填项
- chart values 结构变化
- CRD / API 版本变化
权限与安全变化
- 新权限需求
- root / privileged / capabilities 变化
- 容器用户变化
- 卷挂载、只读根文件系统兼容性变化
本项目遵循最小权限原则。若升级要求更高权限,必须单独指出。
存储与状态数据变化
- 数据迁移
- schema 升级
- 卷路径变化
- 不可逆升级
- 备份或回滚限制
网络与入口变化
- Service port
- 健康检查路径
- ingress / gateway / route
- TLS / auth / header 行为
K8s / Helm / Operator 兼容性
- 最低 Kubernetes 版本
- Helm breaking changes
- CRD 升级步骤
- operator/controller 行为变化
已禁用服务
如果服务当前已关闭,还要检查:
.renovate/packageRules.json5 的 Disabled Packages 是否已覆盖
- 是否应关闭该 PR,而不是继续评估升级内容
输出要求
- 简洁
- 只写结论
- 不要寒暄
- 不要搬运大段 release note
- 没有发现问题就明确写“无”
- 有结论必须有依据
输出模板
始终使用这个结构:
PR <编号/标题>
或:
-
需要变更
path#Lx-Ly:要把 ...
path#Lx-Ly:要新增/删除/调整 ...
-
结论:可直接合并
结论只能是:
- 可直接合并
- 先改配置再合并
- 建议跳过 / 暂缓
- 建议关闭 PR
引用要求
当你写“当前配置关联”或“需要变更”时,必须引用仓库中的实际位置,例如:
k8s/apps/common/example/app/helmrelease.yaml#L10-L42
.renovate/packageRules.json5#L50-L88
要求:
- 只引用真正相关的片段
- 不引用大段无关内容
- 不在没有依据时下结论
信息优先级
按这个顺序取证:
- PR 首个评论
- PR 标题 / 描述
- 上游 release notes
- changelog
- compare / tag 间提交摘要
- 当前仓库配置
不要做的事
- 不要分析上游源码
- 不要输出无关亮点
- 不要写空话,比如“建议测试一下”
- 不要在没有依据时猜 breaking change
- 不要一次性写成长报告
- 不要替用户做最终合并决定
审查节奏
默认流程:
- 选出当前第一个待审 PR
- 输出该 PR 的简洁结论
- 等用户决定:
- 再继续下一个
如果用户要求一次看全部,也要按 每个 PR 独立小节 输出,不要混在一起。
质量标准
一个合格结果应满足:
- 用户能在几十秒内判断这个 PR 要不要继续
- 明确指出有没有必要配置变更
- 如果要改,能直接定位到仓库代码
- 如果 PR 信息不足,已主动补查上游说明
- 输出足够短,方便逐个处理