GitHubは10月1日、プルリクエストの非同期マージAPIを一般提供しました。統合の依頼を送った後、返されたIDで状態を確認する仕組みです。複雑なマージを一回の応答で待ち続けずに済み、変更が多いリポジトリの自動処理を組みやすくなります。ただし、依頼の受付はマージ完了と同じではありません。
単独PR・積み重ねたPR・キューに対応
単独のPRに加え、前の変更を土台に次の変更を重ねる『積み重ねたPR』にも対応します。マージキューへの追加や直接マージができ、権限がある場合にはルールを迂回する選択も含まれます。今回のAPIは、積み重ねたPRを扱える唯一のマージAPIと説明されています。
PUTで依頼し、GETで状態を確認
使い方はPUTでマージを依頼し、返されたリクエストIDを使ってGETで状態を繰り返し確認する流れです。GitHubは、プログラムからマージする際に、従来の同期RESTエンドポイントやGraphQLの操作より、この非同期APIを推奨しています。既存APIが即座に廃止されるという発表ではありません。
受付と完了を分けて自動化する
編集部の見方として、自動化では『送信できた』と『統合できた』を別の状態として持つ必要があります。依頼IDを記録し、完了または失敗を確認してから次の処理へ進める設計が重要です。応答待ちが短くなることを、レビューや検証が不要になったことと混同できません。 ルールの迂回には権限が必要です。API導入に合わせて、呼び出すアカウントの権限、失敗時の扱い、監査記録を確認したいところです。非同期化はCIの成功や安全なマージそのものを保証しません。