Triggerung von Builds bei Code- und Zeitplan-Ereignissen

BuildKite führt Pipelines auf der vom Team kontrollierten Infrastruktur aus und koordiniert Jobs über Build-Agents hinweg. Ein Beam AI Agent triggert einen Build, wenn ein definiertes Ereignis eintritt, wie z. B. ein Code-Push oder ein geplantes Release-Fenster, und liest dann den resultierenden Build-Status, während die Jobs ausgeführt werden. Wenn der Kunde eine Regel genehmigt hat – beispielsweise das einmalige erneute Ausführen eines Builds nach einem bekannten, instabilen Schritt –, wendet der Agent diese automatisch an. Builds, die aus einem neuen oder unbekannten Grund fehlschlagen, werden unverändert belassen und an eine Person weitergeleitet, anstatt wiederholt ohne Fehlerursachenanalyse neu gestartet zu werden.

Verfolgung des Pipeline- und Job-Status

Ein Beam AI Agent liest den Status auf Job-Ebene in einer BuildKite-Pipeline aus und verfolgt, welche Schritte erfolgreich waren, fehlgeschlagen sind oder noch laufen, sowie die Dauer jedes Schritts im Vergleich zu seiner üblichen Laufzeit. Er kann ein Status-Dashboard aktualisieren, einen Kanal benachrichtigen, wenn eine Pipeline abgeschlossen ist, und einen Build als blockiert markieren, wenn ein erforderlicher Schritt nicht abgeschlossen wurde. Wenn ein Schritt auf eine Weise fehlschlägt, die keinem bekannten Muster entspricht, oder weitaus länger als gewöhnlich dauert, leitet der Agent dies an eine Person weiter, anstatt selbst über das weitere Vorgehen zu entscheiden.

Sichtbarkeit von Build-Agents und Infrastruktur

Da BuildKite-Pipelines auf der vom Kunden gehosteten Infrastruktur laufen, kann ein Beam AI Agent die Agent-Verfügbarkeit und die Warteschlangentiefe auslesen (sofern Connector- und Account-Berechtigungen dies zulassen) und prüfen, ob Builds in der Warteschlange stehen, weil Agents ausgelastet oder offline sind. Nach einem festen Zeitplan kann er eine Person benachrichtigen, wenn die Warteschlangentiefe zu lange über einem vereinbarten Niveau bleibt, da dies in der Regel auf ein Kapazitätsproblem hindeutet. Der Agent stellt selbst keine Infrastruktur bereit und startet diese auch nicht neu. Er liefert lediglich das Signal, damit eine Person über Kapazitätsänderungen entscheiden kann.