GitHub Checks ウェブフックトリガー
共通情報
GitHub Checks ウェブフックトリガー は、新しい変更がリモート GitHub リポジトリにプッシュされるたびに、TeamCity ビルドを実行します。 さらに、このトリガーは詳細なビルド結果情報を GitHub に投稿します。
処理された変更セットがプルリクエストの一部である場合、このリクエストのチェックタブに同じビルド結果情報が表示されます。
ビルドサーバーのアドレスを公開したくない場合は、トリガー設定で GitHub チェック実行出力で TeamCity リンクを無効化 オプションにチェックを入れます。 この場合、ビルドステータスメッセージは TeamCity ビルドとビルドログへのリンクを公開しません。
トリガーは GitHub チェック API(英語) を活用し、唯一のコミット検証メカニズムとして使用したり、ネイティブの GitHub アクション(英語)ワークフローを補完したりできます。
制限事項と要件
GitHub Checks ウェブフックトリガー は、バージョン管理システムにアクセスするためにリフレッシュ可能なトークンを使用する VCS ルートを持つビルド構成とのみ互換性があります。 これらのトークンは、 GitHub アプリの接続を介して発行されます。
接続では、 ウェブフックをサポート オプションが有効になっている必要があります。 さらに、トリガーでは、関連する GitHub アプリが
Checks: 読み取りと書き込み権限を持ち、チェック実行およびチェックスイートWeb フックイベントを処理する必要があります。 新しい GitHub アプリ TeamCity 接続を "自動" モードで構成する場合、必要な権限とウェブフックイベントハンドラーはすべてすでに有効になっています。 それ以外の場合、新しい接続を「手動」モードで構成するか、バージョン 2024.07 より前に作成された接続を更新する場合は、GitHub 側でアプリの設定を適宜変更してください。 更新された権限を有効にするには、 認証トークンを再取得する必要もあります。関連する VCS ルートで ブランチとしてタグを使用オプションが有効になっている場合、新しい タグ付きリリース(英語)が作成されても、GitHub チェック Webhook トリガーは新しいビルドを自動的に開始しません。
1 つのビルド構成で GitHub チェックと 標準 VCS トリガーを一緒に使用すると、同じプッシュに対して重複したビルドがトリガーされる可能性があります。 過剰なビルドを回避するには、トリガーを 1 つだけ使用することを検討してください。 詳細については、この YouTrack チケットを参照してください: TW-88928(英語)。
Checks と VCS トリガーの比較
"クラシック" な TeamCity セットアップでは、変更の自動ビルドは次のように構成されます:
TeamCity はリモートリポジトリから新しい変更を収集します。 自動 ポーリング 中、または構成が既存の GitHub アプリ接続 経由で作成された場合に GitHub がポストコミットウェブフックを TeamCity に送信したときに発生することがあります。
VCS トリガーは、独自のスケジュールに従って保留中の変更をチェックし、1 つまたは複数の新しいコミットが利用可能な場合は新しいビルドを生成します。 トリガースケジュールは、コミットの頻度が非常に高い場合に発生する可能性のある、TeamCity による過剰な数のビルド生成を防ぎます。 代わりに、ビルドが新しいコミットをバッチで処理できるバランスの取れたアプローチを提供します。 たとえば、過去 5 分間にプッシュされたすべてのコミットは、1 つの TeamCity ビルドになります。
コミットステータスパブリッシャー 機能が構成されている場合、ビルドステータスが GitHub に返されます。
このセットアップと比較すると、 チェックトリガー には次のような大きな違いがあります。
内部スケジュールはなく、新しいプッシュごとに新しい TeamCity ビルドが生成されることが保証されます。 このメカニズムは、プッシュの発生頻度に関係なく、すべてのプッシュに対してビルドを生成する必要がある場合に適しています。
Markdown 形式のステータス更新を公開するために コミットステータスパブリッシャー は必要ありません。