¿Cómo decirle a TeamCity que trate las fusiones como una sola confirmación cuando trabaje con git?


Recientemente hemos pasado de SVN a git. Trabajamos con una rama principal" release " (master), y ramas de características para cada característica en la que está trabajando un desarrollador. En TeamCity tenemos un proyecto para cada rama de características, y por supuesto un proyecto para el maestro.

Cuando trabajamos con SVN, cada vez que alguien se fusionaba de master a su rama feature o viceversa, la fusión era tratada por TeamCity como una confirmación. Ahora, con git, cada fusión hace que TeamCity muestre todas las confirmaciones que vinieron con esta fusión.

Esto causa algunos problemas, por ejemplo cuando alguien fusiona desde master a su rama feature, y ahora su proyecto de TeamCity muestra "283 cambios pendientes" debido a esa fusión, si las compilaciones fallan, los autores de estos cambios serán notificados, como si hubieran hecho estos cambios en la rama feature.

¿Hay alguna forma de decirle a TeamCity que trate las fusiones de git como confirmación única?

Podríamos resolverlo usando fusiones aplastadas, pero eso es algo que realmente nos gustaría evitar.

Author: Atropo, 2012-12-14

3 answers

Estas son dos soluciones posibles:

  1. Una forma de resolver esto (aunque posiblemente muy incómoda, dependiendo de su situación) es notificar a los usuarios en el nivel de una configuración de compilación en lugar de notificar quién se comprometió/se fusionó. Cree configuraciones de compilación separadas para diferentes ramas temáticas y configure notificaciones por configuración de compilación para que solo se notifique al 'propietario' de la rama temática.

  2. Menos seguro, pero vale la pena intentarlo: Podría configurar notificación por rama(es) temática, por ejemplo, por patrones comodín en la ruta de la rama. Esto debería ser posible mediante un plug-in DYI custom notifier que use, por ejemplo, la propiedad branch name, teamcity.construir.vcs.Sucursal..

Una limitación específica de la notificación por correo electrónico de TeamCity (debería ser fácil de soportar) es que no puede filtrar las notificaciones por una combinación de configuración de compilación e 'Ignorar errores no causados por mis cambios'. Entonces al menos podrías configurar la compilación para la rama principal para que los committers sean notificados, y crear configuraciones específicas solo para los proyectos de la rama temática.

 3
Author: The Nail,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-12-24 17:45:07

Estoy bastante seguro de que este es el mismo problema que tuvimos hace unos días, pero viceversa. Fusionamos una rama dev en master, lo que provocó que TC intentara compilar todos y cada uno de los check-in que formaban parte de la fusión. Obviamente no es lo que queríamos.

Para arreglarlo, mantenga la opción Trigger build on each check-in sin marcar en el Build Trigger.

Obtendrá el historial de cambios completo de la rama de origen, pero TeamCity solo compilará la rama de destino utilizando el último código fusionado. Si esa construcción falla, la fusión debería ser el único notificado.

 26
Author: Jaz Lalli,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-01-04 20:46:41

Esta es una posibilidad remota, y probablemente ya la haya probado, pero ¿podría funcionar aplicar la opción de disparo per check-in a Include several check-ins in build if they are from the same committer? Esto podría ser suficiente para engañar a TC en la construcción de las confirmaciones como un solo paquete.

 4
Author: John Hoerr,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-12-17 01:38:52