3

私の会社では、GitHub Enterprise を使用して、特定の保護されたブランチが更新されると、本番サーバーとテスト サーバーを自動的に更新します。

誰かがプッシュ イベントを送信すると、ペイロードがさまざまなサーバーに配信され、それぞれが小さな Web サーバーを実行してそのようなペイロードを受信します。次に、Web サーバーはペイロードの「ref」要素をチェックして、更新されたブランチがサーバーに対応しているかどうかを確認します。

たとえば、誰かがプッシュ イベントをdevelopmentブランチに送信すると、これが WebHook が prod01 と dev01 の 2 つのサーバーに配信するペイロードの開始点になります。

{
  "ref": "refs/heads/development",
  "before": "e9f64fa5a4bec5f68faf9533050097badf1c4c1f",
  "after": "e86956f39a26e85b850b81643332def33e7f15c6",
  "created": false,
  "deleted": false,
...
}

productionprod01 サーバーは、ブランチが更新されたかどうかを確認します。そうではなかったため、そのサーバーでは何も起こりません。サーバー dev01 は同じペイロードをチェックして、developmentブランチが更新されたかどうかを確認します。("ref": "refs/heads/development") だったので、dev01 は次のコマンドを実行します。

git -C /path/to/dev01/repo reset --hard
git -C /path/to/dev01/repo clean -f
git -C /path/to/dev01/repo pull origin development

ペイロードが正しく配信されると、GitHub Enterprise はこれを返します。

作業ペイロード

ただし、Web サーバーが prd01 または dev01 で実行されていない場合があるため、代わりにこれを取得します。

失敗したペイロード:

これが発生すると、リポジトリを更新し、サーバーに同じ変更があることを期待するというワークフローは機能しません。

失敗したペイロードについて通知を受けるにはどうすればよいですか? 可能であれば、Web サーバーをポーリングしたり、悪いステータスをポーリングしたりするものを設定したくありません。それを除けば、ペイロードのステータス (RESTfully?) をチェックするソリューションは、他の理由でペイロードがまだ失敗する可能性があるため、Web サーバーがまだ実行されているかどうかをチェックするよりも優れています。

編集：内部で確認したところ、現在の監視サービスの1つを設定して、各サーバーのWebサーバーのポートで応答を確認できるようです. 上の画像では 8090 ですが、頻繁に異なります。

これは、Web サーバーが応答していない場合のみを実際にカバーするため、私の理想的な解決策ではありません。ペイロードの配信が失敗する理由は他にもさまざまあります。

4

2 に答える 2

1

まだ Jenkins のインスタンスを持っていない場合は、小さな Jenkins インスタンスを立ち上げます。次に、基本的に任意の数 (1000) までカウントされる Jenkins ジョブを呼び出す同じイベントで発火する別の Webhook を作成し、ターゲット サーバーをチェックして、ペイロードがサーバーに送信されたかどうかを確認します。そうすれば、常に監視する必要がなくなり、Webhook と同時に起動されます。

もちろん、Jenkins Webhook も失敗した場合、Jenkins ソリューションは機能しなくなるため、その接続を完全に防弾にするために作業する必要があります。もちろん、これは非生産的であり、他の場所で時間を費やすほうがよい場合があります.

残念なことに、エンタープライズ向けの GitHub API には、リクエストに対するレスポンス コードを表示する方法がないようです。もちろん、API はリクエストのペイロードを表示できますが、それは明らかに役に立ちません。

于 2016-02-02T21:42:36.527 に答える