Aug 192012
 

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 ;)

Share
Mar 172012
 
Mystery solved; guitar identified

About 16 years ago, I gave guitar lessons at a small music shop in Painesville, OH. In the midst of a slow sales month, the shop manager gave me a used guitar off the wall instead of the money he owed me. Being a Rock Star in my spare time, I saw this as a “free guitar” and took it home to my wife, who said, “Is it edible, Ricky Rock Star? Because we need food on the table.” Of course, fast-forward to today, and she fully supports the decision in retrospect; turning down a “free guitar” in lieu of money you really need is practical and pragmatic and thusly a violation of the Rock Star Code. I didn’t even know what the guitar was. I never asked. [...]

Share
Nov 262011
 

It’s Thanksgiving weekend in the U.S., and that can only mean one thing: it’s time to start homebrewing again. The temperature’s right for fermenting and there’s no better weather for hanging out in the backyard, drinking a beer, and watching 6 gallons of amber liquid boil for an hour or so. Of course, that leaves plenty of time to whip up some Python scripts for homebrewers (well, homebrewers that dig on Python, anyway). Armed with a netbook and 3 Victory Storm King stouts: ccbrew.py

And all good boys write unit tests, right? (OK, OK … this is more like a glorified main() intermingled with some unittest assertions.) test_ccbrew.py

TODO Pretty much everything relevant to water chemistry, mash schedules, gravity, color, and much, much more. I only [...]

Share
Sep 292011
 

These are taken directly from Major League Baseball’s official 2011 season statistics.  2011 Cleveland Indians   2011 Boston Red Sox   Payroll $48,339,167 $160,257,476  Wins 80 90  Cost per win $604,239.59 $1,780,638.62  Playoff revenue  $0 $0  Likeability 7/10 3/10  FAIL rating 7/10 11/10

Share