当社の製品は、GitHubでWebHooksを作成します。顧客プロジェクトごとに1つ。
このような各プロジェクトは、単一のブランチにリンクされています。
GitHubへのPush
が実行されると、対応するWebHookがトリガーされ、次に、対応するエンドポイントに特定のアクションを実行するよう要求します。
一般的なシナリオは、顧客が同じリポジトリの複数の異なるブランチに接続された複数のプロジェクトを持っているというものです。したがって、いくつかの異なるWebHookが同じリポジトリに接続されています。
問題は、ブランチの1つに対してPush
が実行されると、GitHubがすべてのリポジトリ関連のWebHookをトリガーすることです。
特定のブランチにプッシュが行われると、対応するWebHookが1つだけトリガーされると予想されます。
この問題を参照しているように見える2つの投稿(そのうちの1つは2012年のもの)を見つけました。
可能な解決策は、Webhookリクエスト内で送信されたref
パラメータを解析し、それに応じてアクションを実行するタイミングを制御することです(その方向をまだ確認していないため、ref
が常に存在し、右ブランチパス/名前)。しかし、それは「遅すぎます」-それまでにすべてのWebHookがトリガーされているためです...
しかし、GitHubがこの振る舞いをどうにかして構成する方法を持たないのは不合理に思えます。
助けていただければ幸いです。
GitHubサポートに連絡しました。
この投稿がWebHooksとリポジトリ/ブランチの関係を誤解している他の人に役立つことを願っています。
ここに彼らの答えがあります:
観察された動作は予期されたものであり、近い将来に変更する予定はありません。
リポジトリでWebhookを作成し、それをPushイベントにサブスクライブすると、ブランチまたはタグがプッシュされると、Webhookがトリガーされます。
https://developer.github.com/v3/activity/events/types/#pushevent
支店ごとのウェブフックはありません。
したがって、同じリポジトリのPushイベントでサブスクライブする複数のWebhookを作成する代わりに、1つだけ作成し、受信したペイロードからプッシュされたブランチを確認する必要があります(気づいたように、ブランチの名前はrefを介して渡されます)ペイロードのフィールド)。
この答えは、私たちの概念が間違っていることを認識させました。
ブランチはWebhookにマップされません。各WebHookはリポジトリにリンクされ、ブランチへのコミットが行われると、次のように、ブランチはWebHook Webリクエスト内のref
属性内に記述されます。
{
"ref": "refs/heads/branch_name",
...
もう1つ注意すべき点は、GitHubがリポジトリイベントごとに作成されるWebHookの数を制限していることです。
各インストールターゲット(特定の組織または特定のリポジトリ)のイベントごとに最大20のWebhookを作成できます。
それはここから取られました:
https://developer.github.com/webhooks/
これはこのコンテキストでは重要です。Push
イベントのブランチごとにWebHookを作成すると、20のWebHookの制限に達し、追加のWebHookを作成しようとするとエラーが発生します。
リポジトリごとに1つのWebHookでそれを維持することは、その問題を排除します。