2011-07-05 1 views
0

En ce moment, je suis un heureux utilisateur de TeamCity + Maven + Git. J'ai un build comme mvn deploy qui devrait être déclenché par chaque commit dans Git. Tous les tests sont exécutés et tout va bien. =)Comment forcer TeamCity à construire chaque commit en GIt?

Mais ce système a un problème, après que je lance mvn release:prepeare sur ma machine, il crée deux commits (avec les versions, disons, 1.1 et 1.2-SNAPSHOT) dans le centre repo Git dont une est étiquetée avec 1.1. Parce que TeamCity vérifie la dernière version toutes les N secondes, il ne construit réellement que le dernier avec la version 1.2-SNAPSHOT. Et de cette façon, construire 1.1 ne jamais entrer dans Maven repo. Les stratégies de sécurité ne me permettent pas d'exécuter mvn deploy depuis ma propre machine et le déploiement de repo Maven ne peut être effectué qu'à partir de la machine TeamCity.

Ainsi je veux exécuter les deux builds contre les deux commits à repo. Pour autant que je sache, c'est impossible avec une seule version configurée dans TeamCity.

Maintenant j'utilise une solution de contournement: il existe une version supplémentaire qui ne génère que des validations «release», qui est déclenchée par des déclencheurs avec regex de validation. Une autre solution de contournement possible est l'utilisation de la construction supplémentaire qui est construite par rapport à la branche "release" spécialisée. Mais, je ne veux pas avoir de solutions de contournement et je voudrais forcer TeamCity à exécuter la construction contre chaque commit dans Git. Cela m'aidera également à comprendre les tests qui ont échoué.

Répondre

0

Le problème de construction de un build dans TeamCity est que cette construction particulière est liée à une branche (supposons que c'est le tronc). Cependant, quand Maven fait le release:prepare, il crée en fait une étiquette. Lorsque vous créez cette balise, vous ne disposez pas d'une génération, car votre projet existant est lié à la branche d'origine. Ma suggestion serait soit de contourner la politique de votre entreprise, soit de créer des builds séparés pour chaque tag. Nous avions l'habitude d'utiliser TeamCity et nous avons eu votre problème. Je suis le directeur de la construction de l'entreprise et je le libère aussi. Je crois que tant que la construction originale a passé correctement dans le serveur CI, alors il est parfaitement bien de faire mvn release:prepare release:perform et même mvn deploy.

+0

On dirait qu'il n'y a pas de solution de contournement et que je devrais me libérer de la réalité. Ainsi, je vais créer une version supplémentaire sans déclencheurs, qui ne devrait être exécutée que par le gestionnaire de versions, qui, dans le cas contraire, va publier une version et la déployer dans un rapport interne de maven. –