Buildkite

officiel

Gérer les pipelines et les builds de Buildkite.

Que pouvez-vous faire avec Buildkite MCP ?

Comparer les builds pour détecter les régressions — Demandez « Qu'est-ce qui a changé depuis que ce build a fonctionné sur main ? » en utilisant compare_builds avec org_slug, pipeline_slug et build_number.
Examiner les jobs en échec avec les logs — Utilisez get_build_failure_summary ou tail_logs pour examiner les entrées de log des étapes qui échouent nouvellement ou qui échouent toujours après une comparaison.
Épingler une baseline spécifique pour la comparaison — Fournissez baseline_build_number pour comparer avec un build particulier, y compris ceux en échec ou les builds sur d'autres branches.
Comprendre la correspondance des jobs et le timing — Obtenez des détails sur la façon dont les jobs sont mis en correspondance (via les clés d'étape ou le repli sur le nom) et consultez les écarts de temps d'exécution de scheduled_at à started_at.

Documentation

buildkite-mcp-server

Model Context Protocol (MCP) serveur exposant les données Buildkite (pipelines, builds, jobs, tests) aux outils et éditeurs d'IA.

La documentation complète est disponible sur buildkite.com/docs/apis/mcp-server.

Comparaison des builds

L'outil en lecture seule compare_builds de l'ensemble d'outils investigations répond à des questions telles que « Qu'est-ce qui a changé depuis que ce build a fonctionné pour la dernière fois sur main ? ». Fournissez org_slug, pipeline_slug et le build_number cible. Il sélectionne le build antérieur le plus récemment créé qui est actuellement réussi sur le même pipeline et la branche exacte. Il n'exige pas que la référence ait déjà réussi lorsque la cible a démarré. Fournissez baseline_build_number pour comparer avec un build spécifique de ce pipeline à la place, y compris un build échoué ou un build sur une autre branche.

La réponse identifie la référence et la règle de sélection, compte les résultats sur tous les jobs et renvoie jusqu'à 100 comparaisons de jobs, en priorisant les étapes nouvellement échouées, rétablies et toujours en échec. La correspondance utilise les clés d'étape, le type de job, les valeurs de matrice et l'index/total parallèle. Lorsque deux jobs manquent de clés, elle se rabat sur le nom non vide exact plus le type, la clé de groupe, les valeurs de matrice et l'index/total parallèle, uniquement lorsque cette combinaison est unique dans chaque build. Les paires correspondantes exposent match_method: "step_key" ou "name_fallback" ; les correspondances de secours portent un avertissement indiquant qu'elles sont heuristiques. Les jobs sans nom ni clé et les identités en double restent sans correspondance. Les clés explicites ne se rabattent jamais sur les noms, même lorsqu'une clé a été ajoutée, supprimée ou modifiée entre les builds. Ajouté/supprimé signifie qu'une identité de job n'est présente que dans un seul build, donc renommer des jobs sans clé ou modifier les valeurs de matrice ou le parallélisme peut également produire des entrées ajoutées/supprimées. Les tentatives relancées sont exclues ; les états de la dernière tentative et les compteurs de relance restent visibles.

Les temps d'exécution et les écarts couvrent uniquement les dernières tentatives. Le temps de planification est scheduled_at à started_at, pas l'attente de dépendance ou manuelle. Ce ne sont pas des comparaisons de temps mural de build ni des coûts totaux de relance. Les horodatages manquants ou incohérents omettent le timing correspondant. Les builds non terminés sont explicitement identifiés comme des instantanés changeants.

Les transitions entre échecs logiciels et durs sont signalées comme state_changed, même lorsque les deux jobs ont l'état failed. Un build de référence réussi peut contenir des jobs en échec logiciel.

Par défaut, jusqu'à trois jobs nouvellement échoués incluent leurs 20 dernières entrées de journal, limitées à 8 Ko de contenu de journal chacune. Définissez include_logs: false pour omettre les journaux. Les erreurs de journal n'écartent pas la comparaison, sauf les erreurs d'authentification HTTP 401, qui se propagent via le chemin de réauthentification du serveur. L'outil nécessite les portées read_builds et read_build_logs. Utilisez get_build_failure_summary ou tail_logs pour approfondir ; une étape échouée partagée n'établit pas une cause racine commune ni ne rend une relance sûre.

La découverte de référence recherche au plus 500 candidats. Si aucun n'est trouvé, la réponse indique qu'aucune comparaison n'a été effectuée et demande une référence explicite. Les inventaires de jobs sont limités à 1 000 jobs par build ; les inventaires plus importants renvoient une erreur au lieu de résultats ajoutés/supprimés partiels trompeurs. Les omissions de sortie sont signalées séparément des comptes de résultats complets.

Utilisation de la bibliothèque

L'API Go exportée de ce module doit être considérée comme instable et sujette à des changements cassants à mesure que nous faisons évoluer ce projet.

Sécurité

Pour garantir que le serveur MCP est exécuté dans un environnement sécurisé, nous recommandons de l'exécuter dans un conteneur.

Cette image est construite à partir de cgr.dev/chainguard/static et s'exécute en tant qu'utilisateur non privilégié.

Transmission des en-têtes d'identité via le mode HTTP

Les déploiements HTTP auto-hébergés peuvent transmettre des en-têtes sélectionnés de chaque requête MCP entrante à l'API Buildkite :

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

Répétez --passthrough-http-header pour autoriser plus d'un en-tête, ou définissez une valeur BUILDKITE_PASSTHROUGH_HTTP_HEADERS séparée par des virgules. Seuls les en-têtes explicitement autorisés sont transmis, et uniquement à l'origine configurée par BUILDKITE_BASE_URL. Ils sont supprimés des requêtes redirigées ailleurs.

Pour authentifier chaque requête MCP avec son propre jeton API Buildkite, autorisez Authorization et omettez le jeton à l'échelle du processus :

BUILDKITE_PASSTHROUGH_HTTP_HEADERS=Authorization \
  buildkite-mcp-server http

Dans ce mode, chaque requête /mcp doit contenir exactement un en-tête Authorization non vide. Les identifiants manquants renvoient HTTP 401 ; le serveur ne revient jamais à un jeton API partagé. Le proxy inverse devant le serveur MCP est responsable de l'authentification des appelants et de la définition ou de la validation de tout en-tête d'identité transmis.

La transmission d'en-têtes n'est pas disponible en mode stdio. Avant de servir les journaux de jobs, le serveur vérifie que l'appelant actuel peut accéder au journal du job. Cette vérification est effectuée pour chaque requête d'outil de journal, y compris lorsque les données de journal sont déjà en cache.

Contribution

Les directives de développement sont dans DEVELOPMENT.md.

Licence

SPDX-License-Identifier: MIT