TeamCity - Génération de déclenchement sur un fichier spécifique, Mercurial

Question

J'essaie de déclencher la génération uniquement lorsque je crée un Tag dans Mercurial. La im façon d'essayer de le faire est en créant une construction supplémentaire de configuration (Tag Conf) pour mon projet où je mets les VCS construire déclencheur:

+./Hgtags (déclenchement uniquement lorsque les balises sont mises à jour)

-:. (Ne déclenchez pas sur tout autre fichier)

Chaque fois que je pousse un changeset (sans étiquette) dans la vue d'ensemble ma construction conf (Conf Tag) dit « X En attente », je soupçonne que ce sont les changesets. Et quand je crée un Tag dans Mercurial, un build i est déclenché et le X Pending disparaît. Ensuite, il ne me reste plus qu'à mettre à jour les numéros de build/rev dans AssemblyInfo (en quelque sorte) et à déployer les artefacts (en quelque sorte).

Question 1: Est-ce la bonne façon de le faire ou existe-t-il une autre/meilleure façon de le faire? (Im en utilisant runner sln2010 + NUnit + Mercurial)

Question 2: Y at-il un moyen d'obtenir le nom de Tag de la balise afin qu'il puisse être utilisé pour nommer les objets, par exemple?

Cordialement

Answer 1

Q1: Semble un bon moyen. Un moyen plus centré sur Mercurial serait de placer un crochet dans la section [hooks] de Mercurial.ini de l'utilisateur de TeamCity qui soit dit à TeamCity de démarrer une construction, soit touche un fichier séparé qui lance la construction. Cependant, surveiller .hgtags est bien aussi, tant que vous êtes sûr que hg update est en cours d'exécution (le push en soi ne met pas à jour la copie de travail locale en dehors du repo .hg sans hg update ou hg pull -u).

Q2. Souvenez-vous que puisque le fichier .hgtags est lui-même versionné, si vous faites une commande hg tag TAGNAME, vous avez appliqué la balise TAGNAME à la révision tip, mais en faisant cela, vous avez créé un nouveau changeset qui est maintenant le tip, donc votre révision taguée TAGNAME n'est plus le pourboire.

Lorsque vous poussez tous ces changesets vous avez la même considération que j'ai évoquée dans Q1 - à quelle révision hg update? Si vous hg update -r tip (l'action la plus simple et la valeur par défaut), vous passez à une révision après la révision balisée. Heureusement, il existe des éléments de modèle qui sont très utiles pour contourner ce type de situation délicate: {latesttag} et {latesttagdistance}.

Avec ceux que vous pouvez avoir une mise à jour de script de compilation à la dernière étiquette en faisant quelque chose comme:

LATESTTAG=$(hg log --template '{latesttag}') 
hg update -r $LATESTTAG 

, ce qui rend une chaîne de version populaire pour builds qui ne sont pas étiquetés:

VERSION=$(hg log --template '{latesttag}+{latesttagdistance}') 

Windows-ification de ces lignes de commande à gauche comme un exercice pour le lecteur ainsi estropié. :)