flake

Flake

Remotion の CI チェックが失敗し、フレークの可能性がある場合、または /flake の実行を依頼された場合に、このスキルを使用します。

トラッカーの Issue：https://github.com/remotion-dev/remotion/issues/8375

目標

Issue #8375 に CI のフレークによる失敗を記録し、影響を受けたスイートを再び実行できる状態にします。

フレークと確定した場合、またはその可能性が高い場合は、毎回次の手順を行います。

1. PR、ワークフローの実行、ジョブ、失敗したステップ、および簡潔な失敗の特徴を特定します。
2. Issue #8375 を更新します。
   • 特徴がすでに記録されている場合は、その Count を増やします。
   • 新しい特徴の場合は、カウントを 1 とし、ワークフロー／ジョブ、初回確認日、証拠の URL を記載した行を追加します。
3. フレークが発生したジョブ、または失敗したジョブを再実行します。

失敗を見つける

GitHub アプリでは Actions のログや書き込み権限がすべて利用できない場合があるため、gh を優先してください。

ユーザーが 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 の変更がその箇所に影響する可能性が低い。

変更されたソースの動作が原因で発生した型エラー、リンターエラー、スナップショットの不一致、テストのアサーション失敗は、再試行で成功したという証拠がない限り記録しないでください。

特徴のルール

繰り返し発生したケースをまとめられ、かつ対処に必要な具体性も保てる、安定した特徴を使用します。

• 判明している場合は、たとえば @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`

トラッカーを更新する

Issue の本文を読みます。

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

表を維持したまま、Issue の本文全体を編集します。置き換える 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

既知のフレークが発生したジョブが 1 つだけで、実行が完了している場合：

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 を含む、実施した再実行の操作。
• 意図的にそのままにした、引き続き実行中のチェック。