GitHubs asynchrone Merge-API ist allgemein verfügbar und nun empfohlen
Victoria Shinder1 Min. LesezeitGitHub hat seine asynchrone Merge-API allgemein verfügbar gemacht. Sie kann einzelne Pull Requests oder ganze Stapel zusammenführen, Pull Requests in eine Merge-Queue stellen oder direkt mergen – einschließlich des Umgehens von Regeln, wenn der Aufrufer dazu berechtigt ist.
Das Modell ist ein Austausch in zwei Schritten. Eine Automation reicht eine Merge-Anfrage per PUT ein und erhält eine Anfrage-ID, dann fragt sie per GET mit dieser ID den Status ab. Laut GitHub hilft das Automationen bei viel genutzten Repositories, weil ein komplexer Merge nicht mehr innerhalb einer einzigen Anfrage abgeschlossen sein muss.
Das Changelog ist bei der Richtung eindeutig. Die asynchrone Merge-API ist nun der empfohlene Weg, Pull Requests programmatisch zu mergen, anstelle des synchronen REST-Endpunkts und der GraphQL-Mutationen. Zudem ist sie die einzige Merge-API, die gestapelte Pull Requests unterstützt. Als veraltet werden die bisherigen Endpunkte in der Ankündigung nicht bezeichnet, aber die Empfehlung hat sich verschoben.
Parameter und Beispiele stehen in der API-Dokumentation, auf die das Changelog verweist.
Warum das wichtig ist
Bots, die Pull Requests mergen – von Dependency-Updatern bis zu Release-Werkzeugen –, haben meist den synchronen Endpunkt aufgerufen und eine langsame oder fehlgeschlagene Antwort als gescheiterten Merge behandelt. Der Wechsel zu Einreichen und Abfragen ändert die Fehlerbehandlung: Eine Anfrage kann angenommen werden und später trotzdem scheitern, die Automation muss also den endgültigen Status prüfen statt der ersten Antwort. Teams, die gestapelte Pull Requests einführen, haben keine andere API-Option.