TeamCity is a killer Continuous Integration server. Git has become a runaway favorite VCS in the open source community and in many corporate settings alike. And Semantic Versioning (SemVer) has emerged as the way many of us version our software. Yet, the three don’t play together nicely by default: TeamCity doesn’t expose the short hash value of a git commit.

Why is this even an issue? Suppose you want your build numbers to look like 1.2.3+build.45.1c19ff8, where 45 is the TeamCity build number and 1c19ff8 is the short hash of the git commit from which the build was produced. (This is a convention that makes it easy to trace a build back to the exact commit that, for example, introduced a bug.) Since TeamCity only exposes the full git commit hash in its API (%build.vcs.number%) you’re stuck with dead silly build numbers by default if you use a SemVer Build number format like 1.0.0+build.{0}.%build.vcs.number%:

1.2.3+build.45.1c19ff8306eb72e206f44da4ae5ce1644cb66db2

If you’re like me, this makes your eyes bleed. It dances on the edge of human readability. We should like to see instead, a short git hash in the final position (such as what you would see if you issued git rev-parse --short HEAD in a git repo):

1.2.3+build.45.1c19ff8

Much better.

A simple tweak

There is a very simple tweak you can make in your project’s TeamCity build configuration.

1. Set the Build number format to 1.0.0+build.{0} (or whatever the desired major.minor.patch level is.)
2. As the first build step, create a custom script that reads %build.number%, and uses service messages to append the short git hash programmatically.

Here’s an example using a bash script pasted right into the TeamCity GUI (Runner type: Command Line, Run: Custom Script):

If you can’t or don’t want to use a shell script like this, just write a script file in a language for which there is an available runner. For example, Andrew Smith posted a Powershell script that does the same thing on a TeamCity feature request ticket.

A parting thought

I don’t like the use of the word “build” in my build number convention. I’d rather see 1.2.3+45.1c19ff8 instead of 1.2.3+build.45.1c19ff8. Luckily, SemVer does not require this; it’s perfectly legal to drop “build.” The plus (“+”) sign is reserved to indicate a build number follows anyway, so “+build” is technically redundant.

To make this change, update the Build number format to be: 1.0.0+{0} (or, again, whatever you desire in major.minor.patch).

A final parting thought

7 characters is sufficiently unique for most folks’ purposes. If it isn’t for you, you’re either writing software that controls rovers on Mars, or you’re overcomplicating things ;)