flutter-pr-checks-finder

Flutter PR チェック検索

前提条件

• gh（GitHub CLI）がインストールされ、認証済みである必要があります。PATH にない場合は、macOS の /opt/homebrew/bin/gh や Windows の C:\Program Files\GitHub CLI\gh.exe など、一般的な場所を確認してください。
• LUCI から生ログを取得するための curl または同様のツールにアクセスできること。

ワークフロー

1. 失敗したチェックを検索する

gh CLI がインストールされ、認証済みであれば使用できます。利用できない場合は、代替手段として GitHub API に直接 HTTP リクエストを送信できます。

オプション A：gh CLI を使用する（推奨）

チェックを一覧表示するには、次のコマンドを実行します。

gh pr checks <PR_NUMBER>

オプション B：HTTP 経由で GitHub API を使用する

gh を利用できない場合は、read_url_content または同様の方法で公開 GitHub API を利用できます。

1. PR の SHA を検索する： 次の URL に HTTP リクエストを送信します：https://api.github.com/repos/flutter/flutter/pulls/<PR_NUMBER> head.sha フィールドを抽出します。
2. チェック実行を一覧表示する： 次の URL に HTTP リクエストを送信します：https://api.github.com/repos/flutter/flutter/commits/<PR_SHA>/check-runs JSON レスポンスを解析します。重要：失敗を見落とさないよう、ページネーションを処理する必要があります！total_count フィールドを確認します。これが check_runs 配列の項目数（通常は 100 件、または per_page で設定した件数）より大きい場合は、すべてのチェック実行を取得するまで、後続ページごとに URL に ?per_page=100&page=<N> を追加して HTTP リクエストを送信します。失敗したチェック（つまり、conclusion が failure のチェック）をすべて特定します。

失敗したチェックをすべて特定します。

2. 失敗ログを取得する

失敗したチェックごとに、次の手順を実行します。

1. ログ URL を探す：

   • チェックに関連付けられた対象の URL またはリンクを探します。
   • GitHub のチェック表示の下部には、通常「flutter-dashboard で詳細を確認」として flutter-dashboard のリンクが表示されます。
   • または、失敗したチェックの名前と、利用可能であればビルド番号をもとに、LUCI ページへのリンクを再構築できます。 LUCI URL の構造の例：https://ci.chromium.org/ui/p/flutter/builders/try/<Builder Name>/<Build Number>/overview

2. 生ログ URL を作成する：

   • 手動：ログ URL に ?format=raw を追加するか、次の形式に従って生ログ URL を再構築します：https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/<Build ID>/+/u/<Step Name>/stdout?format=raw

3. 生ログを取得する：

   • curl または同様のツールを使って、生ログ URL の内容を取得します。
   • 重要：HTML 形式や出力の切り捨てを避けるため、生ログ URL を使用する必要があります。GitHub API のチェック概要だけに依存しないでください。省略されていたり、完全な情報が含まれていなかったりする場合があります。

ビルダーとステップ名の対応

メモ

ステップ名は非常に具体的で、推測が難しい場合があります。このセクションでは、見つける際に役立つパターンを説明します。

レシピとツール

• flutter_drone レシピ

  • 説明： cocoon または recipes リポジトリに由来します。通常、.ci.yaml (root) で指定されている、シャーディングされたフレームワークのテストや lint（analyze、test_general など）の実行に使用されます。
  • パターン： run test.dart for <shard> shard and subshard <subshard>
  • URL の変換： スペースはアンダースコアに置き換えられます。
  • デフォルト： subshard が指定されていない場合、デフォルトは None です。
  • 例： Linux analyze（シャード：analyze、サブシャードなし）の場合、URL のステップ名は run_test.dart_for_analyze_shard_and_subshard_None です。

• builder.py と関連レシピ

  • 説明： flutter/engine リポジトリ（または recipes リポジトリ）にあり、builders folder ディレクトリ内のターゲット JSON 設定に従ってビルドとテストを実行するために使用されます。
  • パターン： 通常は JSON 設定で指定されたタスク名で、多くの場合 test: が先頭に付きます。
  • URL の変換： スペースはアンダースコアに置き換えられます。
  • 注意点： JSON ファイル内のテスト名がすでに test: で始まっている場合でも、レシピが再度プレフィックスを追加することがあります（例：test:_test:_Check_formatting）。

• tester.py

  • 説明： テストの実行に使用される、engine の CI レシピに共通のヘルパースクリプトです。
  • パターン： Run <shard> tests または Run <shard> <subshard> tests。
  • URL の変換： スペースはアンダースコアに置き換えられます。

Engine で正確な名前を特定する

推測で見つからない場合は、engine の設定で正確なテスト名とタスク名を確認してください。

1. .ci.yaml (engine) でビルダーを調べ、config_name プロパティを確認します。
2. builders folder ディレクトリで、対応する JSON ファイルを探します。
3. JSON ファイルを読み、tests 配列と、その中に記載されている個々の tasks を確認します。

フォールバック

推測したステップ名で read_url_content が 404 エラーになる場合は、LUCI の概要ページやその他の情報源からステップ名を確認する必要があるかもしれません。