每天揪出GitHub Actions里的 flaky 任务

原文要点

这是 n8n 站点发布的免费模板（工作流19072）：按计划每天或手动运行；拉取指定仓库和分支最近已完成的 GitHub Actions 运行，只保留目标工作流的成功/失败记录，run 被重跑时会纳入更早的尝试；分页取回每次尝试的所有 job（完整覆盖矩阵任务）；按 job 名聚合，把任务分为 flaky、confirmed flaky（同一 commit 重跑先败后成）、broken、one-off，并计算 flaky 率和常见失败步骤名；与 n8n Data Table 的 flaky_jobs 历史表比对，只报新增或明显恶化的；用 OpenAI 按可能原因分组，摘要发 Slack，确认的 flaky 建 GitHub issue（有数量上限），最新结果回写 flaky_jobs 表。原文未给出分组提示词全文和分类代码。

这次做成什么

搭一条「定时拉取 Actions 重跑历史→判定 flaky→只报新增/恶化→AI 按原因分组→Slack 摘要+自动建 issue+回写数据表」的巡检流程。因原模板无提示词与代码，本站独立补写分组提示词、合成 job 尝试数据和配置清单，先用假数据验证判定与分支逻辑。

准备什么

• 一个 n8n 实例（1.x 版本，支持 Data Table 功能），能创建计划触发器
• GitHub 个人访问令牌：既能以 Bearer 头读取 Actions，又能用 GitHub 凭据在目标仓库建 issue
• OpenAI API key 及可用聊天模型（调用产生费用）
• Slack 工作区 Bot token 和一个测试频道（如 #ci）
• 一个有多 job（最好含矩阵）且发生过重跑的测试仓库，或接受先用合成数据练习

具体怎么做

1. 建 Settings 与触发器

   加 Schedule Trigger 设为每天早晨（或先手动执行）。在 Settings 节点填 owner、repo、workflow_name（必须与 GitHub Actions 页面显示名完全一致）、branch，以及可选阈值 runs_to_read、min_observations、report_when_worse_by。

2. 配置 GitHub 双凭据

   建一个 HTTP Header Auth 凭据：头名 Authorization，值 Bearer 加你的令牌，用于读 Actions 数据；再建一个 GitHub 凭据用于在目标仓库创建 issue。两个凭据用途不同，别混用。

3. 拉取运行与全部 job

   按模板链路请求目标工作流最近完成的 run，保留 success/failure 状态；对发生过重跑的 run 同时取回更早尝试；对每次尝试分页拉取 jobs，直到翻页结束，保证矩阵任务的每个子 job 都被计入。

4. 聚合判定 flaky

   按 job 名聚合各次尝试结果：同一 commit 先失败后重跑成功记为 confirmed flaky；表现不稳定记 flaky；持续失败记 broken；只出现一次失败记 one-off。同时统计每个 job 的失败率与最常失败的步骤名。观测数低于 min_observations 的 job 不下结论。

5. 与历史表比对

   在 n8n 建名为 flaky_jobs 的 Data Table，列含 job_key、job_name、flake_rate、failures、runs_seen、verdict、last_seen。把本次 flake 率与表内历史值对比，只放行「新增」或恶化幅度超过 report_when_worse_by 的 job 进入报告。

6. AI 分组、输出与回写

   把待报告 job 的名称与失败步骤名交给 OpenAI，用下方分组提示词按可能的间歇性原因归类；格式化摘要发到 slack_channel 指定频道；对 confirmed flaky 按上限创建 GitHub issue；最后把每个 job 的最新 flake 率与判定 upsert 回 flaky_jobs 表。

可直接复制的材料

你是 CI 稳定性分析助手。输入是一组 GitHub Actions 中表现不稳定的 job，每项包含 job 名称和它最常失败的步骤名。
请按最可能的间歇性失败原因把这些 job 分组，常见原因包括：网络/外部服务超时、测试并发或时序竞争、资源不足（内存/磁盘/超时上限）、依赖安装或镜像拉取波动、测试环境数据残留。
只输出一个 JSON 对象，不要输出其他文字，格式：
{"groups": [{"cause": "原因名", "jobs": ["job名1", "job名2"], "suggestion": "一句不超过30字的中文排查建议"}]}
无法归类的 job 放入 cause 为「待人工排查」的组。

[{"job_name":"test (16, ubuntu-latest)","commit":"a1b2c3","attempt1":"failure","attempt2":"success","failing_step":"Run integration tests"},{"job_name":"test (18, ubuntu-latest)","commit":"a1b2c3","attempt1":"failure","attempt2":"failure","failing_step":"Run integration tests"},{"job_name":"build-docker","commit":"d4e5f6","attempt1":"failure","attempt2":"success","failing_step":"docker pull base image"},{"job_name":"lint","commit":"d4e5f6","attempt1":"success","attempt2":null,"failing_step":null}]

{"owner": "your-org", "repo": "demo-service", "workflow_name": "CI", "branch": "main", "runs_to_read": 30, "min_observations": 5, "report_when_worse_by": 0.15, "issue_limit": 3, "slack_channel": "#ci"}

输入与输出示例

本站虚构演示，未实际调用 GitHub/OpenAI/Slack；恶化幅度 0.40=0.50−0.10 为设定值演算。

输入

对上方合成数据跑聚合：test(16) 先败后成、test(18) 两次皆败、build-docker 先败后成、lint 仅一次成功。设历史表中 build-docker 旧 flake 率为 0.10，本次算得 0.50，report_when_worse_by=0.15。

对应输出

判定结果：test (16)=confirmed flaky（同 commit a1b2c3 先败后成），test (18)=broken，build-docker=confirmed flaky 且恶化 0.40 超过阈值 0.15 进入报告，lint=正常不上报。Slack 摘要示例：「⚠️ 新增/恶化 flaky 2 项：test (16) 失败步骤 Run integration tests（疑：测试时序竞争）；build-docker 失败步骤 docker pull base image（疑：镜像拉取波动）」，并为两项 confirmed flaky 各建 1 个 issue，flaky_jobs 表 upsert 两行最新数据。

做完检查这些

• workflow_name 与 GitHub Actions 页面名称逐字一致，否则过滤后无任何 run
• 矩阵 job 的每个子任务都出现在聚合结果里，没有因分页被截断
• 同一 commit 先败后成的 job 被判为 confirmed flaky，且只有这类 job 触发建 issue
• flake 率未超过 report_when_worse_by 的旧 flaky job 不出现在当天 Slack 报告中
• 执行结束后 flaky_jobs 表的 last_seen 与 flake_rate 被更新为本次数值

容易卡住的地方

• 令牌权限不足会读不到 Actions 或建不了 issue，读和写用的是两个不同凭据
• min_observations 设太低会把偶发一次失败误判为 flaky，练习数据量小建议先手动跑
• workflow_name 区分大小写且要完整匹配，含矩阵时 job 名带参数后缀，聚合键要按完整 job 名
• GitHub API 有速率限制，runs_to_read 调太大容易触发限流，具体限额以官方文档为准
• issue 创建有上限设置，超过上限的 confirmed flaky 只进报告不建单，别误以为漏报
• OpenAI 分组与 Slack 发信都依赖凭据与频道权限，Bot 需先被拉进目标频道