CIにおけるWebhookとは？

webhookは、イベントが起きたとき - pushのように - システムが送信するHTTPリクエストで、別のシステムが即座に反応できるようにします。たとえばCIのpipelineを開始するなどです。

変更をpollingするのは無駄で遅いです。webhookはこれを逆転させます。CIが"何か新しいものは？"と尋ねる代わりに、ソースシステムがイベントの発生した瞬間にそれをpushします。このイベント駆動モデルこそ、git pushが即座にビルドをトリガーする仕組みです。

webhookの仕組み

ソースシステムにURLを登録します。選んだイベントが発火すると、システムは何が起きたかを記述するpayloadとともにそのURLへHTTP POSTを送信します。受信側はそれをparseして動作します - たとえばpipelineの実行をキューに入れるなどです。

CIでの一般的な用途

push、pull request、tagでビルドやデプロイをトリガーする。
実行が失敗したときにチャットやインシデントツールに通知する。
オンデマンドでrunnerをプロビジョニングするためにマネージドrunnerプラットフォームを起こす。

簡単な例

pushイベントはJSONのpayload（repo、branch、commit）をあなたのエンドポイントへPOSTします。handlerはそれを検証し、そのcommitのためにpipelineをキューに入れます - git pushをpollingなしで数秒のうちに実行中のビルドへと変えるのです。

webhookの保護

webhookのエンドポイントは公開されてアクセス可能なので、各リクエストを検証しましょう。共有シークレットで計算した署名をチェックし、一致しないpayloadは無視します。検証がなければ、誰でもイベントを偽造できてしまいます。

配信の現実に対処する

webhookは順序が入れ替わって届いたり、複数回配信されたり、timeout後に再送されたりすることがあります。handlerをべき等にし、素早く応答しましょう（重い処理は非同期で行う）。そうすれば遅いhandlerが重複配信を引き起こすことはありません。

重要なポイント

webhookはpollではなく、イベント駆動のHTTPコールバックです。
CIではビルドをトリガーし、通知を送り、runnerをプロビジョニングします。
署名を検証し、リトライに対してhandlerをべき等にしましょう。