TeamCity et la validation de la branche de fusion Git en attente conserve la construction avec des tests ayant échoué

Question

Nous utilisons TeamCity pour une intégration continue et Git pour le contrôle de source. Généralement cela fonctionne plutôt bien - pratique, moderne et bon nous feedback rapide lorsque les tests échouent.

Il existe un comportement étrange lié aux spécificités de fusion Git. Voici les étapes de l'affaire:

1. Le premier développeur tire à partir du repo maître.
2. Le deuxième développeur tire à partir du repo maître.
3. Le premier développeur effectue un commit A localement.
4. Le deuxième développeur effectue la validation B localement;
5. Le deuxième développeur appuie sur la validation B.
6. Le premier développeur souhaite pousser le commit A mais ne peut pas le faire car il doit d'abord tirer le commit B.
7. Premier développeur tire de la redéposition à distance.
8. Le premier développeur pousse la validation A et la validation de la branche de fusion générée.

L'histoire de commits en repo maître est le suivant:

• B second développeur
• Un premier développeur
• branche de fusion premier développeur.

Maintenant, supposons que deuxième développeur a corrigé quelques tests ayant échoué dans son engagement B.

Qu'est-ce que TeamCity fera est le suivant:

1. Engagez B arrive - TeamCity fait construire # 1 avec tous les tests passé

2. Commit A arrive - TeamCity fait que la barre de test # 2 (sans validation B) devient rouge! TeamCity a pensé que la validation "Merge Branch" en attente ne contient aucune modification (aucun nouveau fichier) - mais elle contient en fait la fusion de la validation B, donc TeamCity ne veut pas faire de nouvelle construction ici et faire des tests verts.

Voici deux problèmes: 1. Dans notre cas, nous avons échoué des tests de retour en arrière dans la deuxième commit (validation A) 2. TeamCity ne veux pas faire une nouvelle construction et faire des tests dos vert.

Est-ce que quelqu'un sait comment résoudre ces deux problèmes.

Je considère une approche générale raisonnable.

Answer 1

Ce problème n'a pas encore été corrigé dans la version 5.0.3.Mais il est signalé comme problème connu

Vous pouvez voter pour cette question à http://youtrack.jetbrains.net/issue/TW-9584

Answer 2

Juste pour ajouter, je conseille vivement à l'aide aille chercher --rebase git pull, ou tout simplement ne un git puis faire une révision de ce a changé avec git log -p^master origine/master pour déterminer si je suis d'accord avec ce qui s'est passé en raison du travail des autres développeurs. À ce stade, je peux refaire mon travail sur les changements à distance et teamcity ne vous donnera pas les problèmes que vous voyez ici. Ce n'est pas quelque chose que je fais pour travailler autour de teamcity mais qui fait également partie d'un workflow qui permet un historique plus linéaire et fusionne des résolutions de conflits que vous n'avez pas à revoir si vous fusionnez des fusions précédentes.

HTH,

Adam