Wednesday, May 20, 2009

SvnRevisionLabeller makes its v2 release

Recently Thoughtworks started to make available release candidates for version 1.4.4 of CruiseControl.NET. Tucked away inside there though are some changes to some of the core components, that break compatibility with SvnRevisionLabeller.

This gave me the proper motivation to find some time to finish off the packaging of a fairly major change to the way the labeller constructs build labels. The real work was actually done by another developer, fezguy - I just had to integrate his patch, tweak it to the way I like things (hey, it is my project after all!), and finally start work on some automated tests. I like automated tests.

Since the two changes combined do break backwards compatibility, it's good to take a step back and see where we are now.

Before, SvnRevisionLabeller was quite opinionated about how it thought build labels should be structured. With version 1.1, it was {major}.{minor}.{svnRevision}.{build} - {build} would start at 0, then if you forced another build without another commit having taken place, it would be incremented by one. A commit would then reset {build} back to 0, so you had a good idea how often the build was being forced. I later added the ability to specify prefix and suffix text for the label.

Version 1.3 saw me rethink things a bit, with the label now defaulting to {major}.{minor}.{build}.{svnRevision}; now, successive forced builds made no difference to the label. What it did give me was that when I deployed a hotfix to production (usually designated by the incremented {build} number), I could tell immediately which Subversion revision it was built with.

So it obviously works the way I wanted it to - but what about other people? Version 2.0 makes the label scheme very flexible - some tokens are defined, and you just position the tokens wherever you want them in a string pattern. So for instance, if I set my configuration thusly:

<labeller type="svnRevisionLabeller">
<pattern>Release v{major}.{minor}.{build} from {revision}</pattern>

then when revision 42 is committed, the build label will become Release v1.4.2 from 42. At work, I use the {build} number to represent the sprint number since we began working on the {minor} release.

Finally, I noticed that my project was not the only one to be caught out by CC.NET's upgrade - Codeplex's CC.NET Community Plugins are also broken by the change; unfortunately, they have a little more work to do, as it's not just a question of updating their external libraries and recompiling. I'm rather underwhelmed by the amount of activity on the site: I raised an issue earlier this month, and then submitted a patch to fix the issue, and it still hasn't been acknowledged yet, let alone added to the repository. For the time being, I won't be upgrading to v1.4.4 at work, since we need that library for our deployments.


Unknown said...

Hi David,

Thanks for the update to SvnRevisionLabeller. I am using the release.

Can I confirm whether >build" is a user defined value or automatically generated. I had assumed it was generated value, but I do not think so now.

I am currently using :-


What I would really like is for the labeller to change on every build. This means that I can use <tagOnSuccess>True<tagOnSuccess> in the <sourcecontrol type="svn"> rule. Currently if I force a build it does not change the label and the tag fails because it already exists in the repository.

I know that there is the <rebuild> tag but I do not like the value being reset back to 0 for each.

What I support I want is for <build> to the incremented count of for each build, similar to the default labeller. Perhaps another tag could be added <buildnumber> for using the the pattern string.

Unknown said...

Any plans on releasing a build for 1.4.4 SP1? For whatever funny reason, when I download the current source and compile against the 1.4.4 SP1 libs, NetReflector seems to be unable to find the implementation for the labeller with a type with NetReflector name svnRevisionLabeller does not exist.

David Keaveny said...

{build} can be set by you - it's an optional field in the configuration. Or you can leave it alone, and the labeller should increment it on each forced build (you can set the resetBuildAfterVersionChange field to false if you do not want the build count to reset after a commit).