3

当某些受保护的分支更新时，我的公司使用 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 服务器或轮询不良状态。除此之外，任何检查有效负载状态（RESTfully？）的解决方案都比检查 Web 服务器是否仍在运行要好，因为有效负载可能仍因其他原因而失败。

编辑：我已经在内部进行了检查，看起来我们可能可以设置我们当前的监控服务之一来检查每台服务器上 Web 服务器端口上的响应。在上图中，它是 8090，但它经常不同。

这不是我理想的解决方案，因为它只涵盖了 Web 服务器没有响应的情况。有效载荷传递可能失败的原因还有很多。

4

2 回答 2

1

有两种选择：

实时监控

配置日志转发hookshot_resque并监视错误代码为 422 或 504的失败事件。

基于 Cron 的监控

某些对您的实例具有管理 shell 访问权限的用户可以使用命令行实用程序检查失败的事件ghe-webhook-logs。例如：

显示过去一天所有失败的挂钩交付

ghe-webhook-logs -f -a YYYYMMDD

下一步是解析和自动化命令。虽然这会延迟检测失败的 webhook，但它是可用的最强大和最可靠的方法。

于 2017-03-11T23:32:42.437 回答
1

如果我还没有一个小型 Jenkins 实例，我会怎么做。然后在调用 Jenkins 作业的相同事件上创建一个单独的 webhook 触发，该作业基本上被计算到某个任意数字 (1000)，然后检查目标服务器以查看有效负载是否已发送到服务器。这样，它就不必持续监控，并且会与您的 webhook 同时被触发。

当然，如果 Jenkins webhook 也失败了，Jenkins 解决方案就会失败，所以你必须努力使这种连接真正防弹。当然，这可能会适得其反，最好把时间花在其他地方。

太糟糕了，企业的 GitHub API 中似乎没有任何方法可以查看请求的响应代码。API 当然可以显示请求的有效负载，但这显然对您没有帮助。

于 2016-02-02T21:42:36.527 回答