mcpField
F
flake

flake

github.com/remotion-dev测试与质量68.6k666 次安装今天更新
代码仓库

关于 flake

用于调查疑似不稳定的 Remotion CI 失败，将确认或可能的偶发问题记录到 issue #8375，并重新运行受影响的任务。它提供失败分类、特征整理、跟踪记录和验证步骤。

主要功能

  1. 01检查 GitHub Actions 失败
  2. 02分类可能的偶发失败
  3. 03整理稳定的失败特征
  4. 04更新不稳定问题跟踪表
  5. 05重新运行失败任务

适用场景

  1. 01调查 Remotion PR 检查失败
  2. 02记录重复出现的间歇性故障
  3. 03重试受影响的 CI 任务

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/remotion-dev/remotion --skill flake

安装后在 Claude Code 中输入/flake确认已加载。

详细介绍

Flake

当 Remotion CI 检查失败且看起来像是不稳定故障时，或收到运行 /flake 的请求时，使用此技能。

跟踪问题：https://github.com/remotion-dev/remotion/issues/8375

目标

在问题 #8375 中记录 CI 不稳定故障，并让受影响的测试套件重新运行。

对于每个已确认或疑似的不稳定故障：

  1. 找出 PR、工作流运行、作业、失败步骤和简洁的故障特征。
  2. 更新问题 #8375：
    • 如果已有相同特征，则将其 Count 加 1。
    • 如果是新的，则追加一行，填写计数 1、工作流/作业、首次出现日期和证据 URL。
  3. 重新运行发生不稳定故障的作业或失败的作业。

查找故障

优先使用 gh，因为 GitHub 应用可能无法提供所有 Actions 日志或写入权限。

如果用户提供了 PR：

gh pr view <pr-number> --repo remotion-dev/remotion --json number,title,headRefName,statusCheckRollup
gh pr checks <pr-number> --repo remotion-dev/remotion --watch=false

如果用户提供了工作流运行或作业 URL：

gh run view <run-id> --repo remotion-dev/remotion --json databaseId,attempt,displayTitle,event,headBranch,headSha,status,conclusion,workflowName,createdAt,updatedAt,url,jobs
gh api repos/remotion-dev/remotion/actions/jobs/<job-id>/logs

如果没有 PR 上下文，则检查最近的开放 PR 和最近失败的运行：

gh pr list --repo remotion-dev/remotion --state open --limit 30 --json number,title,headRefName,statusCheckRollup
gh run list --repo remotion-dev/remotion --workflow "Install and Test" --status failure --limit 20 --json databaseId,displayTitle,event,headBranch,headSha,conclusion,createdAt,url,workflowName

尝试重新运行时，先检查原始尝试，再判断故障是否属于不稳定故障：

gh api repos/remotion-dev/remotion/actions/runs/<run-id>/attempts/1/jobs --paginate
gh api repos/remotion-dev/remotion/actions/jobs/<failed-job-id>/logs

判断是否为不稳定故障

符合以下任一条件时，将故障视为不稳定故障：

  • 同一次运行、作业或失败步骤在未更改代码的情况下于重新运行后成功。
  • 故障与基础设施或网络有关，例如 fetch failed、连接重置、包管理器下载失败、缓存服务故障或运行器配置错误。
  • 测试失败是由超时、竞态、浏览器断开连接、端口冲突或间歇性外部服务故障导致，且 PR 的更改不太可能影响该区域。

除非有证据表明重试后能够通过，否则不要记录由更改的源代码行为导致的确定性类型错误、lint 错误、快照错误或测试断言失败。

特征规则

使用稳定的特征来归类重复故障，同时确保其足够具体，以便采取措施：

  • 尽可能包含包或测试套件，例如 @remotion/it-tests#testssr。
  • 尽可能包含测试名称。
  • 包含根错误文本，并去除时间戳、路径、随机 ID、端口、行号和 ANSI 代码。
  • 在跟踪表中单独填写工作流/作业；除非有助于区分，否则不要将其写入特征。

示例：

  • `oven-sh/[email protected]` failed with `TypeError: fetch failed`
  • `delayRender()` timeout while running `Render video with browser instance not open` in `@remotion/it-tests#testssr`

更新跟踪表

读取问题正文：

gh issue view 8375 --repo remotion-dev/remotion --json body --jq .body

编辑完整的问题正文，并保留表格。务必先将替换用的 Markdown 写入临时文件，然后使用 --body-file；不要将多行 Markdown 直接作为内联内容传入。

表格格式：

| Count | Signature | Workflow / job | First seen | Evidence |
| ---: | --- | --- | --- | --- |
| 1 | `signature` | `Workflow` / `Job` | YYYY-MM-DD | https://github.com/remotion-dev/remotion/actions/runs/... |

增加已有行的计数时：

  • 除非证据链接失效或新链接更有用，否则只更改 Count。
  • First seen 保留最早的已知日期。

追加行时：

  • 尽可能使用 GitHub Actions 作业 URL。
  • 如果日志时间戳与本机日期不同，则使用日志时间戳中的当前日期。

编辑后验证：

gh issue view 8375 --repo remotion-dev/remotion --json body --jq .body

重新运行

优先只重新运行失败的作业：

gh run rerun <run-id> --repo remotion-dev/remotion --failed

如果只需重新运行一个已知的不稳定作业，且运行已完成：

gh api --method POST repos/remotion-dev/remotion/actions/jobs/<job-id>/rerun

如果不稳定的测试套件仍在运行，且等待会阻碍任务，则中止该工作流运行，并在确认取消后重新运行失败的作业：

gh run cancel <run-id> --repo remotion-dev/remotion
gh run watch <run-id> --repo remotion-dev/remotion --exit-status
gh run rerun <run-id> --repo remotion-dev/remotion --failed

如果 gh run watch 因取消导致运行失败而以非零状态退出，则继续重新运行失败的作业。

汇报结果

总结：

  • 新增或增加了哪个跟踪问题行。
  • 采取了什么重新运行操作，包括运行或作业 URL。
  • 是否有仍在运行且有意保留不动的检查。

评论

支持 Markdown