Activador de TeamCity para comentario de Github en request de extracción

Tengo mi CI en TeamCity. Actualmente desencadena construcciones en diferentes events (creaciones Pull Request , se fusiona en la twig Develop , etc.). Sin embargo, me preguntaba si es posible activar una compilation específica como resultado de escribir un comentario específico / labelr una Pull Request .

El objective es ejecutar un set de testings de UI automatizadas cuando se ha aprobado una Pull Request extracción (desde un punto de vista de corrección de encoding) y esa twig está list para fusionarse en Develop . No quiero ejecutar ese set de testings de UI automatizadas para cada confirmación en esa twig, ya que lleva alnetworkingedor de 1 hora ejecutarlas y no quiero ejecutarlo solo después de fusionar esa RP para evitar fusionar cualquier cosa que rompa la UI. testings en Develop .

El flujo deseado sería escribir un comentario especial en ese PR, como run_UI_test o labelr el PR con una label personalizada para que las testings se ejecuten en CI y los comentarios se muestren en el PR en Github.

Muchas gracias por adelantado.

No creo que TeamCity tenga conocimiento de los comentarios sobre Github ya que los comentarios en sí mismos no se almacenan directamente en la (s) sucursal (es). Mi suposition es que tienes una raíz VCS similar a esto:

 +:refs/heads/master +:refs/heads/develop +:... +:refs/pull/*/head 

Es posible acceder a los comentarios de una request de extracción a través de la "API de problemas" de GitHub, sin embargo, creo que esto agregaría complejidad innecesaria a su process de compilation y oscurecería cómo se desencadenan las comstackciones.

Mi sugerencia sería seguir un process de IC más tradicional y crear otra capa de "integración" a través de una nueva twig. Así que, básicamente, su flujo se vería así:

  • maestro (requestes de extracción de fusión para publicación)
  • integración (Ejecutar testing de automation de UI)
  • desarrollar (Ejecutar testings de unidades básicas y otras cosas)

Entonces, básicamente, todo su desarrollo ocurre en el desarrollo o en alguna otra twig de "característica". Cuando pasen todas las testings básicas y esté listo para "promocionar", podría fusionarse en la twig de integración que luego activará sus testings de UI. También quiero señalar que esta twig de " integración " de hecho podría ser solo "requestes de extracción" y que no se requiere ninguna twig estática en function de cómo haya configurado el flujo de desarrollo.

es mucho más fácil configurar las reglas de desencadenante y los filters de ramificación en TC, entonces sería escribir algún script de REST API personalizado para trabajar con la API de problemas de GitHub.