⚡

GitHubActions工作流健康检查Skill dyad:check-workflows

该技能用于自动监控 GitHub Actions 工作流的运行状态，识别失败并生成问题报告，确保 CI/CD 流程的稳定性。关键词：GitHub Actions，工作流检查，CI/CD，自动化监控，故障诊断，DevOps

CI/CD 0 次安装 0 次浏览 更新于 3/15/2026

name: dyad:检查工作流 description: 检查过去一天的 GitHub Actions 工作流运行情况，识别严重或持续的失败，并在发现可操作问题时创建 issue。

检查工作流

检查过去一天的 GitHub Actions 工作流运行情况，寻找严重或持续的失败，并在发现可操作问题时创建一个 GitHub issue。

参数

  • $ARGUMENTS: （可选）回溯的小时数（默认：24）

指令

1. 收集最近的工作流运行

获取过去 N 小时（默认 24 小时）的所有工作流运行：

gh run list --limit 100 --json workflowName,status,conclusion,event,headBranch,createdAt,databaseId,url,name

过滤仅包含在回溯时间窗口内创建的运行。按工作流名称分组运行。

2. 对每个失败进行分类

对于每个失败运行，通过检查以下规则确定是 预期的 还是 可操作的：

预期失败（忽略这些）：

  1. 夜间运行器清理：此工作流故意重启自托管的 macOS 运行器，这会中断正在进行的作业进程。即使工作正确，它几乎总是显示为“失败”。始终完全跳过此工作流。

  2. 来自 CI 的级联失败：当主 CI 工作流失败时，这些下游工作流也会失败，因为它们依赖于 CI 工件（例如 html-report、blob 报告）。这是噪音，不是独立问题：

    • Playwright 报告评论（因“工件未找到”而失败）
    • 上传到 Flakiness.io（当没有 flakiness 报告时失败）
    • 当就绪时合并 PR（当 CI 未通过时被跳过/失败）

  3. CLA 助手：失败仅意味着贡献者尚未签署 CLA。这通常会自行解决。

  4. 已取消的运行：由于并发组而取消的运行（新推送取消旧运行）是正常的。

  5. action_required / neutral 结论：GitHub 对 fork PR 或首次贡献者需要手动批准的标准行为。

  6. 非主分支上的 CI 失败：个别 PR CI 失败是预期的——贡献者可能有格式化问题、锁文件不匹配、测试失败等。这是贡献者的责任。

  7. Claude 去 flake E2E：此工作流预计有时会有长时间运行或部分失败，因为它调查 flaky 测试。

可操作失败（标记这些）：

  1. 权限错误：工作流无法访问密钥，缺少 GITHUB_TOKEN，API 调用上出现 403/401 错误（应该已认证），Resource not accessible by integration 错误。

  2. 主分支上持续 CI 失败：如果 CI 工作流在主分支上的 2+ 次连续推送失败，可能某些东西已损坏。检查是否不同提交因相同原因失败。

  3. 基础设施故障：自托管运行器未恢复在线（检查 Nightly Runner Cleanup 的验证步骤是否失败），运行器持续不可用，磁盘空间问题。

  4. 重复速率限制：如果 GitHub API 速率限制导致同一工作流在多次运行中失败（不仅是一次性）。

  5. Action 版本问题：已弃用或损坏的 GitHub Action 版本导致失败。

  6. 工作流配置错误：YAML 语法错误，无效输入，缺少必需密钥（区别于权限问题）。

  7. 计划工作流失败：如果计划/ cron 工作流（除 Nightly Runner Cleanup 外）持续失败，可能表示系统性问题。

3. 调查可操作失败

对于每个潜在可操作失败，获取更多详细信息：

gh run view <run_id> --log-failed 2>/dev/null | head -100

查找：

  • 具体错误消息
  • 失败是在设置步骤（基础设施）还是测试/构建步骤（代码）
  • 相同失败是否出现在多个运行中

4. 确定严重性

调查后，分类可操作失败：

  • 严重：权限错误，基础设施宕机，主分支持续损坏，工作流配置错误
  • 中等：重复速率限制，已弃用 action 警告，间歇性基础设施问题
  • 低：一次性短暂失败，在重试后解决

仅在有严重或中等发现时才继续创建 issue。

5. 检查现有 issue

在创建新 issue 之前，检查是否已有关于工作流问题的 open issue：

gh issue list --label "workflow-health" --state open --json number,title,body

如果现有 issue 涵盖相同问题，不要创建重复项。相反，向现有 issue 添加评论，包含最新发现。

6. 创建 GitHub issue

如果有可操作发现（严重或中等），创建 GitHub issue：

gh issue create --title "工作流问题：<X>, <Y>, 和 <Z>" --label "workflow-health" --body "$(cat <<'EOF'
## 工作流健康报告

**周期：** <开始时间> 到 <结束时间>
**检查的总运行数：** <N>
**发现的失败：** <N 可操作> 可操作，<N 预期> 预期（已忽略）

## 发现的问题

### <问题 1 标题>
- **工作流：** <工作流名称>
- **严重性：** 严重 / 中等
- **失败运行：**
  - [运行 #<id>](<url>) — <日期>
  - [运行 #<id>](<url>) — <日期>
- **错误：** <简要错误描述>
- **建议修复：** <如何解决>

### <问题 2 标题>
...

## 预期失败（已忽略）
<简要总结跳过的预期失败及其原因>

---
*此 issue 由日常工作流健康检查自动创建。*
EOF
)"

issue 标题应列出发现的具体问题（例如，“工作流问题：CI 权限错误，flakiness 上传受速率限制”）。保持简洁但描述性。

7. 报告结果

总结：

  • 检查了多少工作流运行
  • 多少是预期失败（以及哪些类别）
  • 多少是可操作的（以及发现了什么）
  • 是否创建了 issue（带链接）或一切看起来正常
  • 如果未发现可操作问题，报告“所有工作流健康”且不创建 issue