Comment dire à TeamCity de traiter les fusions comme un seul commit lorsqu'on travaille avec git ?

Question

Nous sommes récemment passés de SVN à git. Nous travaillons avec une branche principale "release" (master), et des branches "feature" pour chaque fonctionnalité sur laquelle un développeur travaille. En TeamCity nous avons un projet pour chaque branche de fonctionnalité, et bien sûr un projet pour le master.

Lorsque nous travaillions avec SVN, chaque fois que quelqu'un fusionnait du master vers sa branche de fonctionnalités ou vice-versa, la fusion était traitée par TeamCity comme un seul commit. Aujourd'hui, avec git, chaque fusion entraîne l'affichage par TeamCity de tous les commits qui l'accompagnent.

Cela pose quelques problèmes, par exemple lorsque quelqu'un fusionne du master vers sa branche de fonctionnalités, et que son projet TeamCity affiche maintenant "283 changements en attente" à cause de cette fusion, si les builds échouent, les auteurs de ces changements seront notifiés, comme s'ils avaient fait ces changements sur la branche de fonctionnalités.

Existe-t-il un moyen de demander à TeamCity de traiter les git merges comme un seul commit ?

Nous pourrions résoudre ce problème en utilisant des fusions écrasées, mais c'est quelque chose que nous aimerions vraiment éviter.

Answer 1

Je suis presque sûr qu'il s'agit du même problème que celui que nous avons rencontré il y a quelques jours, mais vice-versa. Nous avons fusionné une branche dev dans master, ce qui a poussé TC à essayer de construire chaque check-in qui faisait partie de la fusion. Ce n'est évidemment pas ce que nous voulions.

Pour y remédier, conservez le Trigger build on each check-in n'est pas cochée dans l'option Build Trigger .

Vous obtenez l'historique complet des modifications de la branche source, mais TeamCity ne construira la branche de destination qu'en utilisant le dernier code fusionné. Si cette compilation échoue, la fusion devrait être la seule à être notifiée.

Answer 2

C'est un peu hasardeux et vous l'avez probablement déjà essayé, mais serait-il possible d'appliquer la méthode per check-in option de déclenchement à Include several check-ins in build if they are from the same committer ? Cela pourrait être suffisant pour inciter TC à construire les commits en un seul paquet.

Answer 3

Il s'agit de deux solutions possibles :

1. Une façon de résoudre ce problème (bien que cela puisse être très gênant, en fonction de votre situation) est de notifier les utilisateurs au niveau d'une configuration de construction plutôt que de notifier qui a fait un commit ou qui a été fusionné. Créez des configurations de compilation distinctes pour les différentes branches du sujet et configurez la notification par configuration de compilation de manière à ce que seul le "propriétaire" de la branche du sujet soit notifié.

2. C'est moins sûr, mais cela vaut la peine d'essayer : Vous pourriez configurer la notification par branche(s) thématique(s), par exemple en utilisant des caractères génériques sur le chemin de la branche. Cela devrait être possible au moyen d'un DYI plug-in de notification personnalisé qui utilise par exemple la propriété du nom de la branche, teamcity.build.vcs.branch.<my_vcs_name> .

Une limitation spécifique de la notification par courriel de TeamCity (qui devrait être facile à prendre en charge) est que vous ne pouvez pas filtrer les notifications par une valeur de combinaison de la configuration de la construction et "Ignorer les échecs qui ne sont pas dus à mes modifications". Vous pourriez alors au moins configurer la construction pour la branche principale de manière à ce que les auteurs soient avertis, et créer des paramètres spécifiques uniquement pour les projets de la branche thématique.