Buildkite

offiziell

Verwalte Buildkite-Pipelines und Builds.

GitHub

Was kann man mit Buildkite MCP machen?

Pipelines auflisten — Bitten Sie den Assistenten, die Pipelines Ihrer Buildkite-Organisation mit list_pipelines zu durchsuchen.
Builds inspizieren — Rufen Sie mit list_builds aktuelle Builds für eine Pipeline ab und tauchen Sie mit get_build in die Details eines bestimmten Builds ein.
Jobs und Logs prüfen — Listen Sie Jobs innerhalb eines Builds mit list_jobs auf und rufen Sie die rohe Log-Ausgabe für einen Job mit get_job_log ab.
Testergebnisse überprüfen — Greifen Sie über list_tests und get_test auf Testzusammenfassungen und einzelne Testdetails für einen Build zu.

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.

Bibliotheksnutzung

Die exportierte Go-API dieses Moduls sollte als instabil betrachtet werden und kann Breaking Changes unterliegen, während wir dieses Projekt weiterentwickeln.

Sicherheit

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

Dieses Image wird aus cgr.dev/chainguard/static erstellt und als nicht-privilegierter Benutzer ausgeführt.

Weiterleiten von Identitäts-Headern im HTTP-Modus

Selbst gehostete 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 kommagetrennten BUILDKITE_PASSTHROUGH_HTTP_HEADERS-Wert. Nur explizit erlaubte Header werden weitergeleitet, und zwar nur an den durch BUILDKITE_BASE_URL konfigurierten Ursprung. Sie werden aus Anfragen entfernt, die an andere Ziele umgeleitet werden.

Um jede MCP-Anfrage mit ihrem eigenen Buildkite-API-Token zu authentifizieren, erlauben Sie Authorization und lassen Sie den prozessweiten 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 niemals auf einen gemeinsam genutzten API-Token zurück. Der Reverse-Proxy vor dem MCP-Server ist für die Authentifizierung der Aufrufer und das Setzen oder Validieren aller weitergeleiteten Identitäts-Header verantwortlich.

Die Header-Weiterleitung ist im stdio-Modus nicht verfügbar. Vor der Bereitstellung von Job-Logs ü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-License-Identifier: MIT