GitHub が Webhook トリガーをチェック

共通情報

GitHub が Webhook トリガーをチェックは、新しい変更がリモート GitHub リポジトリにプッシュされるたびに、TeamCity ビルドを実行します。さらに、このトリガーは詳細なビルド結果情報を GitHub に投稿します。

処理された変更セットがプルリクエストの一部である場合、このリクエストのチェックタブに同じビルド結果情報が表示されます。

ビルドサーバーのアドレスを公開したくない場合は、トリガー設定で GitHub チェック実行出力で TeamCity リンクを無効にするオプションにチェックを入れます。この場合、ビルドステータスメッセージは TeamCity ビルドとビルドログへのリンクを公開しません。

トリガーは GitHub チェック API(英語) を活用し、唯一のコミット検証メカニズムとして使用したり、ネイティブの GitHub アクション(英語)ワークフローを補完したりできます。

制限と要件

• GitHub が Webhook トリガーをチェックは、バージョン管理システムにアクセスするためにリフレッシュ可能なトークンを使用する VCS ルートを持つビルド構成とのみ互換性があります。これらのトークンは、GitHub アプリの接続を介して発行されます。

  接続では、Webhook のサポートオプションが有効になっている必要があります。さらに、トリガーでは、関連する GitHub アプリが Checks: Read and write 権限を持ち、Check run および Check suite Web フックイベントを処理する必要があります。新しい GitHub アプリの TeamCity 接続を「自動」モードで構成する場合、必要な権限と Web フックイベントハンドラーはすべて有効になっています。それ以外の場合、新しい接続を「手動」モードで構成するか、バージョン 2024.07 より前に作成された接続を更新する場合は、GitHub 側でアプリの設定を適宜変更してください。更新された権限を有効にするには、認証トークンを再取得する必要もあります。

• 関連する VCS ルートでブランチとしてタグを使用オプションが有効になっている場合、新しいタグ付きリリース(英語)が作成されても、GitHub チェック Webhook トリガーは新しいビルドを自動的に開始しません。

• 1 つのビルド構成で GitHub チェックと標準 VCS トリガーを一緒に使用すると、同じプッシュに対して重複したビルドがトリガーされる可能性があります。過剰なビルドを回避するには、トリガーを 1 つだけ使用することを検討してください。詳細については、この YouTrack チケットを参照してください: TW-88928(英語)。

チェックと VCS トリガーの比較

「クラシック」TeamCity セットアップでは、自動変更ビルドは次のように構成されます。

1. TeamCity は、リモートリポジトリから新しい変更を収集します。これは、自動ポーリング中に発生する可能性があります。または、構成が既存の GitHub アプリ接続を介して作成された場合は、GitHub がコミット後の Webhook を TeamCity に送信するときに発生する可能性があります。

2. VCS トリガーは、独自のスケジュールに従って保留中の変更をチェックし、1 つまたは複数の新しいコミットが利用可能な場合は新しいビルドを生成します。トリガースケジュールは、コミットの頻度が非常に高い場合に発生する可能性のある、TeamCity による過剰な数のビルドの生成を防ぎます。代わりに、ビルドが新しいコミットをバッチで処理できるバランスの取れたアプローチを提供します。例: 過去 5 分間にプッシュされたすべてのコミットは、単一の TeamCity ビルドになります。

3. ステータス発行者のコミット機能が構成されている場合、ビルドステータスが GitHub に返されます。

このセットアップと比較すると、チェックトリガーには次のような大きな違いがあります。

• 内部スケジュールはなく、新しいプッシュごとに新しい TeamCity ビルドが生成されることが保証されます。このメカニズムは、プッシュの発生頻度に関係なく、すべてのプッシュに対してビルドを生成する必要がある場合に適しています。

• Markdown 形式のステータス更新を公開するためにステータス発行者のコミットは必要ありません。