example - ¿Hay alguna forma de separar los webhook de GitHub en tres categorías: master, pull-request y anything-else?

github webhooks

Question

Lo que estoy tratando de lograr es la siguiente configuración de trabajo de Jenkins ( http://jenkins-ci.org ):

1. Tener un conjunto de trabajos de <project>-master desencadenados por

   • Un impulso a la rama principal de ese proyecto en particular.
   • Manualmente, haciendo clic en "Build Now"
   • Por un script que usa la API REST.

   Lo he logrado especificando el refspec apropiado, agregué el webhook de GitHub, etc. Fue bastante sencillo.

2. Haga que un conjunto de trabajos de <project>-pr sean activados por

   • Una creación de GitHub PR.
   • Un comentario al PR que activa el generador de solicitudes de extracción de GitHub.
   • Un empujón a la rama que se usó para un PR particular.

   He hecho que Jenkins haga los dos primeros. Pero no encontré la manera de hacer el elemento n. ° 3 de esta lista porque los plugins de GitHub no pueden encontrar fácilmente si el push es para una rama de PR o no. ¿Alguna idea de cómo se puede hacer esto?

3. Tener un conjunto de <project>-branch jobs que se desencadenan mediante CUALQUIER inserción en CUALQUIER rama. El problema es que quiero excluir los empujes al maestro y a las ramas que se usan para los RP. He buscado en Internet una posible solución durante días y no he encontrado nada, por lo que cualquier pista será muy apreciada.

Answer 1

1. Para que un trabajo solo se desencadene mediante cambios en la rama principal, no necesita meterse con el webook github. Simplemente puede usar la especificación de la rama git plugins para designar que este trabajo solo debe ejecutarse para la rama principal.

2. Al configurar un trabajo para utilizar el plugin Github Pull Request Builder como se recomienda, solo se activará un PR, para las 3 condiciones que enumeró.

3. el más difícil. Por lo que yo sé, no hay una manera fácil para que jenkins sepa si una rama tiene una solicitud de extracción o no, ya que las solicitudes de extracción son específicas de github, y la detección de rama de jenkins solo está usando git.

Sin embargo, desde mi experiencia, para esta tercera opción, configuré un trabajo de <project>-feature , y lo configuré para que coincida con cualquier rama con un prefijo f/ . De esta forma, si un desarrollador quería que las pruebas se ejecutaran automáticamente contra su sucursal, pero no deseaba abrir una solicitud de extracción en su contra, podrían crear allí una rama como f/add_a_thing , y automáticamente activará las pruebas en los empujes. Para que esto funcione, establecería el especificador de ramas en f/* en la configuración del trabajo.

Alternativamente, el plugin git permite un parámetro de expresión regular para el especificador de rama. Puede usar una expresión regular para ignorar específicamente la rama principal. Sin embargo, la única forma de ignorar las ramas solicitadas es haciendo que los desarrolladores usen un patrón de denominación, como pr/add_a_thing , para identificar que esta rama tendrá una solicitud de extracción.