Buildkite

offiziell

Verwalte Buildkite-Pipelines und Builds.

Was kann man mit Buildkite MCP machen?

Builds vergleichen, um Regressionen zu finden — Fragen Sie „Was hat sich seit diesem Build geändert, der zuletzt auf main funktioniert hat?" mit compare_builds und org_slug, pipeline_slug und build_number.
Fehlgeschlagene Jobs mit Logs untersuchen — Verwenden Sie get_build_failure_summary oder tail_logs, um Logeinträge für neu fehlschlagende oder weiterhin fehlschlagende Schritte nach einem Vergleich zu prüfen.
Eine bestimmte Baseline für den Vergleich festlegen — Geben Sie baseline_build_number an, um mit einem bestimmten Build zu vergleichen, einschließlich fehlgeschlagener Builds oder Builds auf anderen Branches.
Job-Matching und Timing verstehen — Erhalten Sie Details dazu, wie Jobs abgeglichen werden (über Step-Keys oder Namens-Fallback) und sehen Sie Ausführungszeitdeltas von scheduled_at bis started_at.

Dokumentation

buildkite-mcp-server

Model Context Protocol (MCP) Server, der Buildkite-Daten (Pipelines, Builds, Jobs, Tests) für KI-Tools und Editoren bereitstellt.

Die vollständige Dokumentation ist verfügbar unter buildkite.com/docs/apis/mcp-server.

Builds vergleichen

Das schreibgeschützte compare_builds-Tool im investigations-Toolset beantwortet Fragen wie „Was hat sich geändert, seit dieser Build zuletzt auf main funktioniert hat?“ Geben Sie org_slug, pipeline_slug und den Ziel-build_number an. Es wählt den zuletzt erstellten früheren Build aus, der aktuell auf derselben Pipeline und exakt demselben Branch erfolgreich ist. Es ist nicht erforderlich, dass die Baseline bereits erfolgreich war, als der Ziel-Build gestartet wurde. Geben Sie baseline_build_number an, um stattdessen mit einem bestimmten Build in dieser Pipeline zu vergleichen, einschließlich eines fehlgeschlagenen Builds oder eines Builds auf einem anderen Branch.

Die Antwort identifiziert die Baseline und die Auswahlregel, zählt die Ergebnisse über alle Jobs hinweg und gibt bis zu 100 Job-Vergleiche zurück, wobei neu fehlgeschlagene, wiederhergestellte und weiterhin fehlgeschlagene Schritte priorisiert werden. Der Abgleich verwendet Schritt-Keys, Job-Typ, Matrix-Werte und Parallel-Index/-Gesamtzahl. Wenn beiden Jobs Keys fehlen, wird auf den exakten nicht leeren Namen plus Typ, Gruppen-Key, Matrix-Werte und Parallel-Index/-Gesamtzahl zurückgegriffen, jedoch nur, wenn diese Kombination in jedem Build eindeutig ist. Abgeglichene Paare zeigen match_method: "step_key" oder "name_fallback"; Fallback-Abgleiche enthalten eine Warnung, dass sie heuristisch sind. Unbenannte Jobs ohne Keys und doppelte Identitäten bleiben unverglichen. Explizite Keys fallen nie auf Namen zurück, selbst wenn ein Key zwischen Builds hinzugefügt, entfernt oder geändert wurde. Hinzugefügt/entfernt bedeutet, dass eine Job-Identität nur in einem Build vorhanden ist. Das Umbenennen von Jobs ohne Keys oder das Ändern von Matrix-Werten oder Parallelität kann daher ebenfalls hinzugefügte/entfernte Einträge erzeugen. Wiederholte Versuche sind ausgeschlossen; Zustände des letzten Versuchs und Wiederholungszahlen bleiben sichtbar.

Ausführungszeiten und Abweichungen decken nur die letzten Versuche ab. Die Planungszeit ist scheduled_at bis started_at, nicht Wartezeit auf Abhängigkeiten oder manuelle Wartezeit. Dies sind keine Build-Wanduhr-Vergleiche oder Gesamtkosten für Wiederholungen. Fehlende oder inkonsistente Zeitstempel lassen die entsprechenden Zeitangaben weg. Unfertige Builds werden ausdrücklich als sich ändernde Snapshots identifiziert.

Übergänge zwischen weichen und harten Fehlern werden als state_changed gemeldet, selbst wenn beide Jobs den Zustand failed haben. Ein erfolgreicher Baseline-Build kann Jobs mit weichen Fehlern enthalten.

Standardmäßig enthalten bis zu drei neu fehlgeschlagene Jobs ihre letzten 20 Log-Einträge, begrenzt auf 8 KiB Log-Inhalt pro Job. Setzen Sie include_logs: false, um Logs wegzulassen. Log-Fehler verwerfen den Vergleich nicht, außer HTTP-401-Authentifizierungsfehler, die über den Reauthentifizierungspfad des Servers weitergegeben werden. Das Tool erfordert die Bereiche read_builds und read_build_logs. Verwenden Sie get_build_failure_summary oder tail_logs zur weiteren Untersuchung; ein gemeinsamer fehlgeschlagener Schritt begründet keine gemeinsame Ursache und macht eine Wiederholung nicht sicher.

Die Baseline-Erkennung durchsucht höchstens 500 Kandidaten. Wenn keiner gefunden wird, antwortet die Antwort, dass kein Vergleich durchgeführt wurde, und fordert eine explizite Baseline an. Job-Inventare sind auf 1.000 Jobs pro Build begrenzt; größere Inventare geben einen Fehler zurück, anstatt irreführende partielle hinzugefügte/entfernte Ergebnisse zu liefern. Auslassungen in der Ausgabe werden getrennt von den vollständigen Ergebnissen gemeldet.

Bibliotheksnutzung

Die exportierte Go-API dieses Moduls sollte als instabil betrachtet werden und kann sich im Laufe der Entwicklung dieses Projekts mit bahnbrechenden Änderungen ändern.

Sicherheit

Um sicherzustellen, dass der MCP-Server in einer sicheren Umgebung ausgeführt wird, empfehlen wir, ihn in einem Container auszuführen.

Dieses Image basiert auf cgr.dev/chainguard/static und läuft als Benutzer ohne Privilegien.

Identitäts-Header im HTTP-Modus weiterleiten

Self-hosted HTTP-Bereitstellungen können ausgewählte Header von jeder eingehenden MCP-Anfrage an die Buildkite-API weiterleiten:

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

Wiederholen Sie --passthrough-http-header, um mehr als einen Header zuzulassen, oder setzen Sie einen durch Kommas getrennten BUILDKITE_PASSTHROUGH_HTTP_HEADERS-Wert. Nur ausdrücklich erlaubte Header werden weitergeleitet, und nur an den Ursprung, der durch BUILDKITE_BASE_URL konfiguriert ist. Sie werden aus Anfragen entfernt, die an andere Orte umgeleitet werden.

Um jede MCP-Anfrage mit einem eigenen Buildkite-API-Token zu authentifizieren, erlauben Sie Authorization und lassen Sie das prozessweite Token weg:

BUILDKITE_PASSTHROUGH_HTTP_HEADERS=Authorization \
  buildkite-mcp-server http

In diesem Modus muss jede /mcp-Anfrage genau einen nicht leeren Authorization-Header enthalten. Fehlende Anmeldeinformationen geben HTTP 401 zurück; der Server fällt nie auf ein gemeinsames API-Token zurück. Der Reverse-Proxy vor dem MCP-Server ist für die Authentifizierung der Aufrufer und das Setzen oder Validieren weitergeleiteter Identitäts-Header verantwortlich.

Die Header-Weiterleitung ist im Stdio-Modus nicht verfügbar. Bevor Job-Logs bereitgestellt werden, überprüft der Server, ob der aktuelle Aufrufer auf das Job-Log zugreifen kann. Diese Prüfung wird für jede Log-Tool-Anfrage durchgeführt, auch wenn die Log-Daten bereits zwischengespeichert sind.

Mitwirken

Entwicklungsrichtlinien finden Sie in DEVELOPMENT.md.

Lizenz

SPDX-Lizenzkennung: MIT