¿Notificación en WebHooks de GitHub fallidos?

Mi empresa utiliza GitHub Enterprise para actualizar automáticamente los serveres de producción y testing cuando se actualizan ciertas twigs protegidas.

Cuando alguien envía el evento push, se envía una carga útil a varios serveres, cada uno de los cuales ejecuta un pequeño server web para recibir dichas cargas útiles. El server web luego verifica el elemento "ref" de la carga para ver si la twig actualizada se corresponde con el server.

Por ejemplo, cuando alguien envía el evento push a la twig de development , este es el inicio de la carga útil que el WebHook entrega a dos serveres, prod01 y dev01.

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

El server prod01 comtesting si se ha actualizado la twig de production . No fue así, así que no sucede nada en ese server. El server dev01 comtesting la misma carga útil para ver si se actualizó la twig de development . Fue ("ref": "refs / heads / development"), por lo que dev01 ejecuta los siguientes commands.

 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 

Cuando la carga útil se entrega correctamente, GitHub Enterprise devuelve esto.

Carga de trabajo

Pero a veces el server web no se ejecuta en prd01 o dev01, por lo que obtenemos esto.

Carga fallida: "No pudimos entregar esta carga útil: tiempo de espera de servicio"

Cuando esto sucede, nuestro flujo de trabajo para actualizar el repository y esperar que el server tenga los mismos cambios no funciona.

¿Cómo puedo ser notificado de cargas útiles fallidas? Prefiero no configurar algo para sondear los serveres web o sondear en busca de estados incorrectos, si eso es posible. Salvo eso, cualquier solución que verifique el estado (¿RESTfully?) De la carga útil es mejor que verificar si el server web aún se está ejecutando, ya que la carga aún puede fallar por otros motivos.

Editar : lo he revisado internamente y parece que probablemente podríamos configurar uno de nuestros services de supervisión actuales para verificar las respuestas en el puerto del server web en cada server. En la image de arriba, es 8090, pero con frecuencia es diferente.

Esta no es mi solución ideal, ya que solo cubre el caso cuando el server web no responde. Hay una variedad de otras razones por las cuales la entrega de la carga útil puede fallar.

Hay dos opciones:

Monitoreo en time real

Configure el reenvío de logs y supervise los events fallidos en hookshot_resque con los códigos de error 422 o 504.

Monitoreo basado en Cron

Algunos usuarios que tienen acceso de shell administrativo a su instancia pueden verificar events fallidos usando la utilidad de command-line ghe-webhook-logs . Por ejemplo:

mostrar todas las entregas fallidas de ganchos el día anterior

ghe-webhook-logs -f -a YYYYMMDD

El siguiente paso es analizar y automatizar el command. Si bien esto introduce un retraso en la detección de un webhook fallido, es el método más robusto y confiable disponible.

Cómo lo haría sería defender una pequeña instancia de Jenkins, si no tuviera una. A continuación, cree un cobro webhook independiente en los mismos events que llama a un trabajo de Jenkins que se count básicamente a un número arbitrario (1000) y luego verifique los serveres de destino para ver si la carga se envió a los serveres. De esta forma no tendría que estar monitoreando constantemente y se dispararía al mismo time que su webhook.

Por supuesto, la solución de Jenkins se cae si el webhook de Jenkins también falla, por lo que tendría que trabajar para que esa connection sea realmente a testing de balas. Lo cual, por supuesto, podría ser contraproducente y pasar mejor el time en otro lugar.

Es una lástima que no parece haber ninguna manera en la API de GitHub para que la empresa vea el código de respuesta a las requestes. La API, por supuesto, puede mostrar las cargas útiles de las requestes, pero obviamente eso no te ayudará.