TeamCity - Build triggering on specific file, Mercurial

Question

Hi

I'm trying to get my build to trigger only when i create a Tag in Mercurial. The way im trying to do this is by creating an additional Build Config (Tag Conf) for my project where I set the VCS build trigger to:

+:/.hgtags (Trigger only when tags are updated)

-:. (Do not trigger on any other files)

Whenever i push a changeset (without a Tag) in the overview my build conf (Tag Conf) says "X Pending", i suspect this is the changesets. And when I create a Tag in Mercurial, a build i is triggered and the X Pending goes away. Then all there is left for me todo is to update build/rev numbers in AssemblyInfo (somehow) and deploy the Artifacts(somehow).

Question 1: Is this the correct way to do this or are there another/better way to do this? (Im using sln2010 runner + NUnit + Mercurial)

Question 2: Is there a way to get the Tag name out of the Tag so that it can be used for naming the artifacts for example?

Kind Regards

Answer 1

Q1: Seems a fine way. A more mecurial-centric way would be to put a hook in the [hooks] section of the TeamCity user's Mercurial.ini that either tells TeamCity to start a build, or touches a separate file that kicks off the build. However, watching for .hgtags is fine too, so long as you're sure hg update is being run (the push in and of itself doesn't update the local working copy outside of the .hg repo without hg update or hg pull -u).

Q2. Remember that since the .hgtags file is itself versioned, if you do a hg tag TAGNAME command you've applied the tag TAGNAME to the tip revision, but in doing so you've created a new changeset that is now the tip, so your revision tagged TAGNAME is no longer the tip.

When you push all those changesets you have the same consideration I alluded to in Q1 -- to which revision do you hg update? If you hg update -r tip (the easiest action and the default) you're updating to one revision past the tagged revision.

Fortunately, there are some template items that are very useful for getting around just that sort of tricky situation: {latesttag} and {latesttagdistance}.

With those you can have a build script update to the latest tag by doing something like:

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

and this makes a popular version string for builds that weren't tagged:

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

Windows-ification of those command lines left as an exercise for the thusly crippled reader. :)