关于 GitHub 个 WebHook 失败的通知？
Notification on failed GitHub WebHooks?
我公司使用 GitHub Enterprise 在某些受保护的分支更新时自动更新生产和测试服务器。
当有人发送推送事件时，一个有效载荷被传送到各种服务器，每个 运行 一个小型网络服务器来接收这样的有效载荷。 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 returns this.
但有时网络服务器不在 prd01 或 dev01 上 运行，所以我们得到这个。
发生这种情况时，我们更新存储库并期望服务器具有相同更改的工作流程将不起作用。
我如何收到负载失败的通知？如果可能的话，我宁愿不设置一些东西来轮询网络服务器或轮询不良状态。除此之外，任何检查有效负载状态（RESTfully？）的解决方案都比检查 Web 服务器是否仍然 运行 更好，因为有效负载仍可能由于其他原因而失败。
编辑：我已经在内部检查过，看起来我们可以设置我们当前的监控服务之一来检查每台服务器上网络服务器端口的响应。在上图中，它是 8090，但它经常不同。
这不是我理想的解决方案，因为它只真正涵盖了 Web 服务器没有响应的情况。负载传送可能失败的其他原因有很多。
如果我还没有 Jenkins 实例的话，我会怎么做呢？然后创建一个单独的 webhook 触发调用 Jenkins 作业的相同事件，该作业基本上被计算为某个任意数字 (1000)，然后检查目标服务器以查看有效负载是否已发送到服务器。这样一来，它就不必持续监控，并且会与您的 webhook 同时被触发。
当然，如果 Jenkins webhook 也失败，Jenkins 解决方案就会失败，因此您必须努力使该连接真正防弹。当然，这可能会适得其反，最好将时间花在其他地方。
太糟糕了，在 GitHub API 中似乎没有任何方法可以让企业查看请求的响应代码。 API 当然可以显示请求的有效负载，但这显然对您没有帮助。
有两种选择：
实时监控
配置 log forwarding 并监控 hookshot_resque 中错误代码为 422 或 504 的失败事件。
基于 Cron 的监控
一些用户administrative shell access to your instance can check for failed events using the command line utility ghe-webhook-logs。例如：
显示过去一天所有失败的挂钩交付
ghe-webhook-logs -f -a YYYYMMDD
下一步是解析和自动化命令。虽然这会延迟检测失败的 webhook，但它是可用的最稳健和可靠的方法。
我公司使用 GitHub Enterprise 在某些受保护的分支更新时自动更新生产和测试服务器。
当有人发送推送事件时，一个有效载荷被传送到各种服务器，每个 运行 一个小型网络服务器来接收这样的有效载荷。 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 returns this.
但有时网络服务器不在 prd01 或 dev01 上 运行，所以我们得到这个。
发生这种情况时，我们更新存储库并期望服务器具有相同更改的工作流程将不起作用。
我如何收到负载失败的通知？如果可能的话，我宁愿不设置一些东西来轮询网络服务器或轮询不良状态。除此之外，任何检查有效负载状态（RESTfully？）的解决方案都比检查 Web 服务器是否仍然 运行 更好，因为有效负载仍可能由于其他原因而失败。
编辑：我已经在内部检查过，看起来我们可以设置我们当前的监控服务之一来检查每台服务器上网络服务器端口的响应。在上图中，它是 8090，但它经常不同。
这不是我理想的解决方案，因为它只真正涵盖了 Web 服务器没有响应的情况。负载传送可能失败的其他原因有很多。
如果我还没有 Jenkins 实例的话，我会怎么做呢？然后创建一个单独的 webhook 触发调用 Jenkins 作业的相同事件，该作业基本上被计算为某个任意数字 (1000)，然后检查目标服务器以查看有效负载是否已发送到服务器。这样一来，它就不必持续监控，并且会与您的 webhook 同时被触发。
当然，如果 Jenkins webhook 也失败，Jenkins 解决方案就会失败，因此您必须努力使该连接真正防弹。当然，这可能会适得其反，最好将时间花在其他地方。
太糟糕了，在 GitHub API 中似乎没有任何方法可以让企业查看请求的响应代码。 API 当然可以显示请求的有效负载，但这显然对您没有帮助。
有两种选择：
实时监控
配置 log forwarding 并监控 hookshot_resque 中错误代码为 422 或 504 的失败事件。
基于 Cron 的监控
一些用户administrative shell access to your instance can check for failed events using the command line utility ghe-webhook-logs。例如：
显示过去一天所有失败的挂钩交付
ghe-webhook-logs -f -a YYYYMMDD
下一步是解析和自动化命令。虽然这会延迟检测失败的 webhook，但它是可用的最稳健和可靠的方法。