GitHub WebHooks失敗的通知？

Question

我的公司使用GitHub Enterprise在更新某些受保護的分支時自動更新生產和測試服務器。

當有人發送推送事件時，有效負載被傳送到各個服務器，每個服務器運行一個小型Web服務器以接收這樣的有效負載。 然后，Web服務器檢查有效負載的“ref”元素，以查看更新的分支是否與服務器對應。

例如，當有人將推送事件發送到development分支時，這是WebHook提供給兩個服務器prod01和dev01的有效負載的開始。

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

prod01服務器檢查production分支是否已更新。 它不是，因此該服務器上沒有任何反應。 服務器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服務器或輪詢錯誤的狀態。 除此之外，任何檢查有效負載狀態（RESTful？）的解決方案都比檢查Web服務器是否仍在運行更好，因為有效負載可能仍然因其他原因而失敗。

編輯 ：我在內部進行了檢查，看起來我們可能會設置一個當前的監控服務來檢查每台服務器上Web服務器端口的響應。 在上圖中，它是8090，但它經常不同。

這不是我理想的解決方案，因為它只涵蓋Web服務器沒有響應時的情況。 有效負載傳遞可能失敗的原因還有很多。

Answer 1

如果我還沒有一個小Jenkins實例，我將如何做到這一點。 然后在調用Jenkins作業的相同事件上創建一個單獨的webhook，該作業基本上被計為某個任意數字（1000），然后檢查目標服務器以查看有效負載是否已發送到服務器。 這樣就不必持續監控，並且會在您的webhook同時被解雇。

當然，如果Jenkins webhook也失敗了，Jenkins解決方案就會失敗，所以你必須努力使這種連接真正具有防彈性。 當然，這可能適得其反，而且時間更好。

在GitHub API中似乎沒有任何方法可以讓企業查看請求的響應代碼。 API當然可以顯示請求的有效負載，但這顯然不會對您有所幫助。

Answer 2

有兩種選擇：

實時監控

在hookshot_resque配置日志轉發和監視失敗事件，錯誤代碼為422或504。

基於Cron的監控

某些對您的實例具有管理shell訪問權限的用戶可以使用命令行實用程序ghe-webhook-logs檢查失敗事件。 例如：

顯示過去一天所有失敗的鈎子交付

ghe-webhook-logs -f -a YYYYMMDD

下一步是解析和自動化命令。 雖然這會導致檢測到失敗的webhook的延遲，但它是最可靠和最可靠的方法。