用途
fix-buildkite-ci 用于诊断和修复 RisingWave 项目中失败的 Buildkite CI 检查。其目标是避免仅凭 UI 截图猜测问题，而是通过结构化 JSON 和产物检查，定位确切的失败测试用例和不匹配内容，然后实施最小的正确修复。
目标选择
排查目标按以下优先级确定：
- 若用户提供 Buildkite 构建 URL，直接使用该构建。
- 否则，若用户指定分支和/或流水线（例如 pull-request、main-cron），使用指定范围。
- 否则，默认使用当前 git 分支，并检查与该分支关联 PR 的检查。
工作流程
- 识别失败的 Buildkite 构建。
- 获取构建 JSON 并列出失败的任务。
- 拉取任务日志并提取第一个具体失败信号。
- 当顶层日志被截断时，检查产物。
- 将失败映射到根因并应用聚焦修复。
- 在可行时进行本地验证并汇总证据。
优先使用 bk CLI。若认证不可用，通过 curl 使用公开的 Buildkite JSON/日志/产物端点。具体命令和端点模式参见 references/buildkite-ci-triage.md。
步骤
步骤 1：识别失败的 Buildkite 检查
未指定明确目标时，先找到当前分支对应的 PR，然后运行 gh pr checks <PR_NUMBER> 找出失败的检查并捕获 Buildkite URL（.../builds/<N>）。
若用户指定分支/流水线，使用这些参数通过 bk build list 列出并过滤构建。若用户提供 Buildkite 构建 URL，跳过发现阶段，直接从该构建号开始。
步骤 2：拉取构建 JSON 与失败任务
获取 builds/<N>.json，然后按非零 exit_status 列出失败任务。至少捕获：
- pipeline
- build number
- job id
- job name
- exit status
步骤 3：提取具体失败
获取每个失败任务的日志，搜索高信号模式：
- query result mismatch
[Diff] (-expected|+actual)- query is expected to fail with error:
- panic/assertion 行
- 确定性模拟错误标记
- OOM/超时/取消标记
一旦获得一个具体失败文件/用例和不匹配内容即停止。
步骤 4：回退到产物
若日志只显示包装错误（例如 command exited with status），检查同一任务的产物，尤其是：
- risedev-logs.zip
- risedev-logs/nodetype-*.log
解压并搜索产物日志中的确切不匹配。
步骤 5：应用聚焦修复
优先采用与证据关联的最小修复：
- SQLLogicTest 不匹配：仅当查询输出变更为预期行为时，更新正确的 .slt/.slt.part 文件中的期望部分。
- 运行时行为错误：修复源代码，保持测试不变。
- 仅 Flaky/取消信号（143）：视为基础设施/取消问题，除非有产品错误佐证。
- 避免在没有根因证据的情况下进行宽泛的“重试并祈祷”操作。
步骤 6：验证并报告
尽可能运行最窄的本地检查来验证修复。若无法进行完整验证，明确说明。
始终报告：
- 失败的检查/构建/任务标识
- 失败的文件/测试/用例
- 确切的不匹配/错误证据
- 应用的修复（更改的文件）
- 验证状态和剩余风险
Buildkite 特定启发式
- 退出代码 105：通常是 docker-compose/插件的包装失败；检查 SLT/e2e 日志寻找真正的不匹配。
- 退出代码 4：常见于模拟/恢复步骤；检查上传的模拟日志。
- 退出代码 143：通常是取消/终止，而非确定性产品回归。
- JSON 中的 raw_log_url 可能为 null；使用按 job id 指定的显式任务日志端点。
- 优先使用 JSON 端点加 jq；避免抓取大型 HTML 页面。