Buildkite führt pipeline-spezifische Geheimnisse und neue agentische Werkzeuge ein
21. Oktober 2026 · 3 Min. Lesezeit
Der Anbieter für kontinuierliche Integration Buildkite hat pipeline-spezifische Geheimnisse sowie neue Werkzeuge für das Modellkontextprotokoll eingeführt, die dazu dienen, Pipelines zu validieren, fehlgeschlagene Builds zu diagnostizieren und Webhooks zu reparieren. Das Unternehmen hat zudem die Unterstützung für Linux arm64 in seine Kompatibilitätsschicht für GitHub Actions aufgenommen und die OpenTelemetry-Daten in Buildkite Agent Version 4.1.0 erweitert.
Die neue Ansicht für Geheimnisse ist unter den Pipeline-Einstellungen verfügbar. Sie ermöglicht es Ingenieuren, Cluster-Geheimnisse zu erstellen, deren Zugriff auf die aktuelle Pipeline beschränkt ist, anstatt jedes Geheimnis über die breitere Cluster-Oberfläche zu verwalten. Teams können Bedingungen für einen Branch, eine Warteschlange, eine Build-Quelle oder einen Build-Ersteller hinzufügen. Die Werte der Geheimnisse bleiben nach der Erstellung verborgen. Laut Matt Mejia hält diese Änderung pipeline-spezifische Geheimnisse zusammen, während sie zeigt, wie viele andere Geheimnisse der Cluster verwaltet. Benutzer benötigen sowohl die Berechtigung, die Pipeline zu bearbeiten, als auch deren Cluster zu verwalten. GitHub-Actions-Pipelines zeigen vor ihrem ersten Workflow-Lauf einen Hinweis an, der zur Konfiguration der Geheimnisse verlinkt.
Die umfangreichsten Funktionsänderungen betreffen den quelloffenen MCP-Server von Buildkite. Das neue Werkzeug validate_pipeline prüft die YAML-Syntax und Struktur von Pipelines gegen das offizielle Schema von Buildkite, ohne sie hochzuladen oder einen Build zu starten. Es gibt Pfade und Fehlermeldungen zurück, die ein KI-Coding-Agent verwenden kann, um ungültige Schritte zu korrigieren. Die Prüfung deckt keine Interpolation von Umgebungsvariablen, Plugin-Konfigurationen, Abhängigkeitsreferenzen oder dynamisch generierte Schritte ab. Ein zweites Werkzeug, compare_builds, vergleicht einen fehlgeschlagenen Build mit dem letzten erfolgreichen Build auf demselben Branch oder mit einem anderen ausgewählten Build. Es meldet Schritte, die neu fehlgeschlagen sind, wiederhergestellt wurden oder weiterhin fehlerhaft sind, zusammen mit Änderungen in Laufzeit und Wiederholungen. Für bis zu drei neu fehlerhafte Schritte enthält es das Ende des Job-Logs, damit ein Agent sofortigen diagnostischen Kontext hat.
Die MCP-Veröffentlichung fügt auch Ausführungsspuren des Test-Engines und Abfragen für die langsamste Ausführung hinzu. Ein weiteres Werkzeug, create_pipeline_webhook, kann einen fehlenden GitHub-Webhook zu einer vorhandenen Pipeline hinzufügen, wodurch die Notwendigkeit vermieden wird, sie neu zu erstellen. Version 1.23.0 änderte create_pipeline so, dass Aufrufer create_webhook angeben müssen, was eine brechende Änderung darstellt. Buildkite hat einen früheren Standard nach Durchführung von Auswertungen umgekehrt, da Fehlerzusammenfassungen nun wieder Jobs enthalten, die nie ausgeführt wurden, da die Optionales Verhalten dazu führte, dass Agenten zusätzliche Werkzeugaufrufe auslösten. Remote-MCP-Verbindungen können nun auf eine Buildkite-Organisation festgelegt werden, indem diese zur Server-URL hinzugefügt wird.
Die Kompatibilitätsschicht für GitHub Actions kann ihren Importer und generierte Jobs nun auf Linux-arm64-Agenten ausführen. Labels wie ubuntu-24.04-arm erfordern eine explizite Warteschlangenzuordnung und fallen nicht auf x86-64 oder Emulation zurück. Diese Funktion ermöglicht Organisationen mit arm64-CI-Flotten, diese Architektur beizubehalten, wenn sie kompatible Actions-Workflows zu Buildkite bringen. Weitere Kompatibilitätskorrekturen lösen Umgebungs-, benannte Geheimnis-, Laufzeit- und Matrixwerte in der Service-Container-Konfiguration auf. Buildkite hat auch mehr strategy.*-Werte für Job- und Schritt-Ausdrücke offengelegt. Die Grenze für geänderte Dateien, die von Pfadfiltern verwendet wird, ist von 300 auf 3.000 gestiegen, zusammen mit einer Korrektur für Push-Workflows, bei denen sich ein Branch nach dem ursprünglichen Push verschoben hat.
Agent Version 4.1.0 fügt Dauer und Größe des Cache-Speicherns und -Wiederherstellens zu den Buildkite-Telemetriedaten hinzu. OpenTelemetry-Job-Spans enthalten nun den Commit, den Pull Request und den Build-Autor. Diese Felder fügen Kontext für Teams hinzu, die langsame Jobs oder Wiederholungsmuster untersuchen. Die zugehörige Elastic CI Stack Version 7 bringt Agent Version 4 auf Linux- und Windows-Instanzen bei AWS. Sie entfernt die Unterstützung für Agent Version 3 und stellt einige Verfolgungs- und Abbruchparameter ein oder ersetzt sie. Buildkite rät Benutzern, benutzerdefinierte Parameterdateien, Deployment-Automatisierung und über AgentEnvFileUrl übergebene Werte vor dem Upgrade zu überprüfen. Die Unterstützung für alle Agent-Version-3-Veröffentlichungen endet am 3. September 2027.