How can I label my build with revision number and not the GUID (in TeamCity)?

Question

I am trying to do \"continuous integration\" with TeamCity. I would like to label my builds in a incremental way and the GUID provided by the VCS is not as usefull as a simple i

Answer 1

The best and easiest way to see rev. number in TeamCity build number is to use Build Script Interaction with TeamCity. Namely, it has a possibility to set Build Number.

So, add to your project a new very first build step Command Line with following Command Executable

for /f %%i in ('c:\tortoisehg\hg id -n') do echo ##teamcity[buildNumber '%%i']

And you will get the Mercurial revision number as a label for your every build.

Of course you can change the command in quotes to anything you wish.

I believe my answer is way more correct than the accepted one.

EDIT:

Also you can do the same via MSBuild task rather than Command Executable. Have a MSBuild project file with following code, setup TeamCity to run it as first step, and it will alter its global variable buildNumber:

<Message Text="##teamcity[buildNumber '$(CurrentVersion)']" Importance="High" />

Where CurrentVersion is a string containing full version (for example "1.0.56.20931").

Answer 2

When I used to use Subversion I used to do something similar in TeamCity. The format was:

{Major}.{Minor}.{TeamCity Build No.}.{Subversion Revision No.}

This allowed me to look at an assembly and see which build it came from on TeamCity and the revision number from subversion.

I have now moved to Git which has put me in the same situation as you. After playing with various ideas I have come to the conclusion that I don't actually need the revision, the build is good enough. Because TeamCity is such a powerful tool, all you need is the build number, given the build number you can look at the build history and determine the revision from that.

{Major}.{Minor}.{Macro}.{TeamCity Build No.}

Additionally you can get TeamCity to label your repository with the build number allowing you to look up a given build in your source control.

Answer 3

As Lasse V. Karlsen mentioned those numerical revision numbers are local-clone specific and can be different for each clone. They're really not suitable for versioning -- you could reclone the same repo and get different revision numbers.

At the very least include the node id also creating something like 0.0.12-6ec760554f2b then you still get sortable release artifacts but are still firmly identifying your release.

If you're using numeric tags to tag releases there's a particularly nice option:

% hg log -r tip --template '{latesttag}.{latesttagdistance}'

which, if the most recent tag on that clone was called 1.0.1 and was 84 commits ago gives a value like:

1.0.1.84

Since you can have different heads that are 84 commits away from a tag in different repos you should still probably include the node id like:

% hg log -r tip --template '{latesttag}.{latesttagdistance}-{node|short}'

giving:

1.0.1.84-ec760554f2b

which makes a great version string.

Answer 4

hg id produces the hash (6ec760554f2b), hg id -n produces the local revision number (12).

(Note this is an answer purely from the hg side, how you then get that into TeamCity, I don't know, as I've never used it.)

Answer 5

I managed to use it in Teamcity using a workaround:

    <Exec Command="hg log -r tip --template {latesttag}.{latesttagdistance} > $(BuildAgentTempDir)\version.txt"/>
    <ReadLinesFromFile File="$(BuildAgentTempDir)\version.txt">
        <Output TaskParameter="Lines" ItemName="versionInfo"/>
    </ReadLinesFromFile>
    <TeamCitySetBuildNumber BuildNumber="@(versionInfo)-{build.number}" />

If you see the MSBuild task "TeamCitySetBuildNumber" I'm using the "{build.number}" variable because it substitutes this with what you set in the build number originally. I used %build.vcs.number% in my original settings (in the Web UI) and the result is just what Ry4an wrote above!

Hope it works for you!

Answer 6

When providing your build number with numeral mercurial revision, you must be aware, that those numbers are clone-specific and can differ from clone to clone.

In our project we had the same issue. We're using TeamCity 7.1.1. We solved it in the following way:

1. Add Command line build step to your configuration.
2. Make this build step run first.
3. In the build step properties select "Run: 'Executable with parameters'"
4. Add the following text to Command Executable:

for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%%i']

 Save changes.

You can also use previously generated build number when performing step 3.

Example:

for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%system.build.number%.%%i']

You can use this to make build counter present in your build number.

Read this to get more information!

Remember that teamcity compiles configurations build number before build starts and the correct build number will appear only after your build step will finish its job. That's why, in some cases (f.e. inserting your mercurial revision into artifact's name) you should define build number's value in preceding configuration and refer to it.

Example:

%dep.bt82.build.number%

Read this to get more information!