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

team city cost

Question

Recientemente nos mudamos de SVN a git. Trabajamos con una rama principal de "publicación" (principal) y contamos con ramas para cada función en la que un desarrollador está trabajando. 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 maestro a su rama de características o viceversa, TeamCity trataba la fusión como una confirmación. Ahora, con git, cada fusión hace que TeamCity muestre todos los commits que vinieron con esta combinación.

Esto causa algunos problemas, por ejemplo, cuando alguien se fusiona desde el maestro a su rama de características, y ahora su proyecto TeamCity muestra "283 cambios pendientes" debido a esa fusión, si las compilaciones fallan, los autores de estos cambios serán notificados, como si lo hicieran. estos cambios en la rama de características.

¿Hay alguna manera de decirle a TeamCity que trate las fusiones de git como compromiso único?

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

Answer 1

Esta es una posibilidad Include several check-ins in build if they are from the same committer , y probablemente ya lo haya intentado, pero ¿podría funcionar aplicar la opción de activación per check-in para Include several check-ins in build if they are from the same committer ? Esto podría ser suficiente para engañar a TC para que cree las confirmaciones como un único paquete.

Answer 2

Estas son dos posibles soluciones:

1. Una forma de resolver esto (aunque posiblemente sea muy incómodo, 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 cometió / se fusionó. Cree configuraciones de compilación separadas para diferentes ramas de tema y configure la notificación por configuración de compilación para que solo se notifique al "propietario" de la rama de tema.

2. Menos seguro, pero vale la pena intentarlo: puede configurar la notificación por rama (s) de tema, por ejemplo, mediante patrones comodín en la ruta de la rama. Esto debería ser posible mediante un complemento de notificador personalizado DYI que use, por ejemplo, la propiedad de nombre de rama, teamcity.build.vcs.branch.<my_vcs_name> .

Una limitación específica de la notificación por correo electrónico de TeamCity (debería ser fácil de admitir) es que no puede filtrar las notificaciones mediante una combinación de configuración de compilación y "Ignorar fallos no causados ​​por mis cambios". Entonces, al menos, podría configurar la compilación para la rama principal para que se notifique a los committers, y crear configuraciones específicas solo para los proyectos de las ramas temáticas.

Answer 3

Estoy bastante seguro de que este es el mismo problema que tuvimos hace unos días, pero viceversa. Combinamos una rama de desarrollo en maestro, lo que provocó que TC intentara construir todos y cada uno de los registros que formaban parte de la fusión. Obviamente no es lo que queríamos.

Para solucionarlo, mantenga la Trigger build on each check-in opción de Trigger build on each check-in desactivada en Build Trigger .

Obtiene el historial de cambios completo de la rama de origen, pero TeamCity solo creará la sucursal de destino utilizando el último código fusionado. Si esa construcción falla, la fusión debe ser la única notificada.