fix-buildkite-ci について
Buildkite CIの失敗をビルド・ジョブ情報、ログ、成果物から調査し、絞り込んだ修正につなげるスキルです。対象選定からローカル検証までを導き、根拠に基づく報告を支援します。
主な機能
- 01URL、ブランチ、パイプラインでビルドを選択
- 02ビルドJSONと失敗ジョブを確認
- 03ログや成果物から具体的なエラーを特定
- 04的を絞った修正とローカル検証
- 05失敗の根拠と残るリスクを報告
活用シーン
- 01PRのBuildkiteチェック失敗の調査
- 02成果物から切れたログの原因を追跡
- 03製品の不具合とキャンセルの区別
- 04対象を絞ったCI修正の検証と記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/fix-buildkite-ciを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yamlreferences/buildkite-ci-triage.md
詳細
Buildkite CI の修正
概要
Buildkite の失敗をプログラムで診断し、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 が 0 以外の失敗したジョブを一覧表示します。
少なくとも次の情報を記録します。
- パイプライン
- ビルド番号
- ジョブ ID
- ジョブ名
- 終了ステータス
ステップ 3：具体的な失敗を抽出する
失敗した各ジョブのログを取得し、次のような重要度の高いパターンを検索します。
query result mismatch[Diff] (-expected|+actual)query is expected to fail with error:- panic／アサーションの行
- 決定論的シミュレーションのエラーマーカー
- OOM／タイムアウト／キャンセルのマーカー
具体的な失敗ファイル／ケースと不一致が 1 つ特定できたら、そこで調査を終了します。
ステップ 4：アーティファクトを調査する
ログにラッパーエラー（例：コマンドがステータス付きで終了）しか表示されない場合は、同じジョブのアーティファクト、特に次のものを調査します。
risedev-logs.ziprisedev-logs/nodetype-*.log
アーティファクトのログを展開し、正確な不一致を検索します。
ステップ 5：的を絞った修正を適用する
根拠に基づく最小限の修正を優先します。
- SQLLogicTest の不一致：クエリ出力の変更が意図したものである場合に限り、正しい
.slt／.slt.partファイルの期待値のセクションのみを更新します。 - 実行時の動作の誤り：テストはそのままにして、ソースコードを修正します。
- 不安定な動作／キャンセルのみを示す兆候（
143）：製品のエラーによる裏付けがない限り、インフラまたはキャンセルの問題として扱います。
根本原因を示す根拠のない、広範な「再試行してうまくいくことを期待する」対応は避けます。
ステップ 6：検証して報告する
可能であれば、修正を検証できる最小範囲のローカルチェックを実行します。完全な検証が難しい場合は、その旨を明示します。
必ず次の内容を報告します。
- 失敗したチェック／ビルド／ジョブの識別情報
- 失敗したファイル／テスト／ケース
- 不一致／エラーの正確な根拠
- 適用した修正（変更したファイル）
- 検証状況と残るリスク
Buildkite 固有のヒューリスティクス
- 終了コード
105：docker-compose／プラグインが原因のラッパーエラーであることがよくあります。真の不一致を特定するため、SLT／e2e のログを調査します。 - 終了コード
4：シミュレーション／リカバリのステップでよく見られます。アップロードされたシミュレーションログを調査します。 - 終了コード
143：通常はキャンセル／終了を示し、決定論的な製品のリグレッションではありません。 - JSON の
raw_log_urlが null の場合があります。ジョブ ID を使って明示的なジョブログのエンドポイントを使用します。 - JSON エンドポイントと
jqを優先し、大きな HTML ページのスクレイピングは避けます。