Buildkite

公式

Buildkiteのパイプラインとビルドを管理します。

GitHub
54

Buildkite MCPで何ができますか？

  • ビルドを比較して回帰を見つける — compare_builds に org_slug、pipeline_slug、build_number を指定して、「このビルドがmainで最後に成功してから何が変わったか」を確認します。
  • ログで失敗したジョブを調査する — 比較後に新たに失敗したステップや引き続き失敗しているステップのログエントリを調べるには、get_build_failure_summary または tail_logs を使用します。
  • 比較のための特定のベースラインを固定する — baseline_build_number を指定すると、特定のビルド（失敗したビルドや他のブランチのビルドを含む）と比較できます。
  • ジョブのマッチングとタイミングを理解する — ジョブがどのようにマッチされるか（ステップキーまたは名前のフォールバックによる）の詳細を取得し、scheduled_at から started_at までの実行時間の差分を確認します。

ドキュメント

buildkite-mcp-server

Build status

Model Context Protocol (MCP) サーバー。Buildkite のデータ（パイプライン、ビルド、ジョブ、テスト）を AI ツールやエディタに公開します。

完全なドキュメントは buildkite.com/docs/apis/mcp-server で参照できます。

ビルドの比較

読み取り専用の compare_builds ツール（investigations ツールセット内）は、「このビルドが main で最後に成功してから何が変わったか」といった質問に答えます。org_slug、pipeline_slug、および対象の build_number を指定します。このツールは、同じパイプラインかつ同一ブランチで現在成功している、直近に作成された以前のビルドを選択します。ベースラインが対象ビルドの開始時点で成功している必要はありません。baseline_build_number を指定すると、そのパイプライン内の特定のビルド（失敗したビルドや別ブランチのビルドを含む）と比較できます。

レスポンスは、ベースラインと選択ルールを特定し、全ジョブの結果数を集計し、最大100件のジョブ比較を返します。新たに失敗したステップ、回復したステップ、引き続き失敗しているステップが優先されます。マッチングは、ステップキー、ジョブタイプ、マトリックス値、並列インデックス/総数を使用します。両方のジョブにキーがない場合、完全一致の非空白名とタイプ、グループキー、マトリックス値、並列インデックス/総数にフォールバックしますが、その組み合わせが各ビルド内で一意である場合に限ります。マッチしたペアは match_method: "step_key" または "name_fallback" を公開します。フォールバックマッチには、ヒューリスティックであることを示す警告が付きます。名前がなくキーもないジョブや重複した識別情報はマッチしません。明示的なキーは、ビルド間でキーが追加、削除、変更された場合でも、名前にフォールバックすることはありません。追加/削除は、ジョブの識別情報が一方のビルドにのみ存在することを意味するため、キーのないジョブの名前変更や、マトリックス値や並列処理の変更でも追加/削除エントリが発生する可能性があります。再試行された試行は除外されます。最終試行の状態と再試行回数は表示されたままです。

実行時間と差分は最終試行のみを対象とします。スケジュール時間は scheduled_at から started_at までであり、依存関係や手動待機時間は含まれません。これらはビルドのウォールクロック比較や再試行の総コストではありません。タイムスタンプが欠落または不整合な場合、対応するタイミングは省略されます。未完了のビルドは、スナップショットが変化しているものとして明示的に識別されます。

ソフト失敗とハード失敗の間の遷移は、両方のジョブの状態が failed であっても、state_changed として報告されます。成功したベースラインビルドにソフト失敗したジョブが含まれる場合があります。

デフォルトでは、最大3つの新たに失敗したジョブについて、各ジョブの最後の20件のログエントリ（各8 KiBのログコンテンツに制限）が含まれます。include_logs: false を設定するとログを省略できます。ログエラーは比較を破棄しません。ただし、HTTP 401認証エラーは例外で、サーバーの再認証パスを通じて伝播します。このツールには read_builds と read_build_logs のスコープが必要です。さらに調査するには get_build_failure_summary または tail_logs を使用してください。共有された失敗ステップは、共有された根本原因を確立するものではなく、再試行を安全にするものでもありません。

ベースラインの検出は最大500件の候補を検索します。見つからない場合、レスポンスは比較が実行されなかったことを示し、明示的なベースラインを要求します。ジョブの一覧はビルドごとに最大1,000ジョブに制限されています。それより大きい一覧は、誤解を招く部分的な追加/削除結果の代わりにエラーを返します。出力の省略は、完全な結果数とは別に報告されます。

ライブラリの使用法

このモジュールのエクスポートされたGo APIは不安定と見なされ、プロジェクトの進化に伴い破壊的な変更が行われる可能性があります。

セキュリティ

MCPサーバーを安全な環境で実行するために、コンテナ内での実行を推奨します。

このイメージは cgr.dev/chainguard/static から構築され、非特権ユーザーとして実行されます。

HTTPモードでのIDヘッダーの転送

セルフホスト型のHTTPデプロイメントでは、各インバウンドMCPリクエストから選択したヘッダーをBuildkite APIに転送できます：

BUILDKITE_API_TOKEN=bkua_xxx \
  buildkite-mcp-server http \
  --passthrough-http-header X-User-Identity

--passthrough-http-header を繰り返して複数のヘッダーを許可するか、カンマ区切りの BUILDKITE_PASSTHROUGH_HTTP_HEADERS 値を設定します。明示的に許可されたヘッダーのみが転送され、BUILDKITE_BASE_URL で設定されたオリジンにのみ転送されます。他の場所にリダイレクトされたリクエストからは削除されます。

各MCPリクエストを独自のBuildkite APIトークンで認証するには、Authorization を許可し、プロセス全体のトークンを省略します：

BUILDKITE_PASSTHROUGH_HTTP_HEADERS=Authorization \
  buildkite-mcp-server http

このモードでは、すべての /mcp リクエストに、空でない Authorization ヘッダーが正確に1つ含まれている必要があります。資格情報がない場合はHTTP 401が返されます。サーバーが共有APIトークンにフォールバックすることはありません。MCPサーバーの前にあるリバースプロキシが、呼び出し元の認証と、転送されるIDヘッダーの設定または検証を担当します。

ヘッダーのパススルーはstdioモードでは利用できません。ジョブログを提供する前に、サーバーは現在の呼び出し元がジョブログにアクセスできることを検証します。このチェックは、ログデータがすでにキャッシュされている場合を含め、すべてのログツールリクエストに対して実行されます。

コントリビューション

開発ガイドラインは DEVELOPMENT.md にあります。

ライセンス

MIT © Buildkite

SPDX-License-Identifier: MIT