Git labeller, branches and dynamic values

After some use of the Git labeller for CCNET described in my previous post, we were faced with an unexpected problem.

On a project following the basic workflow described here, we had the following scenario:

• At some point of time, release tag 'v1.1.200.0' was placed on 'qa' branch and that version went into production
• Later, while development continued on the 'master' and 'qa' branches, a fix was needed for the previous release, so we've created a branch 'release1.1.200' from the last release tag, commited the fixes into it, and placed a new tag 'v1.1.200.1' on the last commit of the release branch - pushing both the commits and the tags to the origin.
• On the CCNET automated build, when getting the code using the Git source control plugin, we specified 'release1.1.200' as the branch to use, and expected to get '1.1.200.1' as the CcNetLabel

But instead of that, we kept getting a '1.1.200.0' label  ¿?

By following the CCNET server log, we've found out that the sequence in which the Git source control plugin works is:

1. repository is cloned or updated
2. labeller is invoked
3. branch specified in CCNET configuration is checked out (!)

So when the labeller tries to get the last tag by invoking git describe, it receives something like 1.1.200.0-xxx where xxx specify the commits present after that tag.

Once the problem was clear, the solution was to add to the labeller configuration an (optional) element specifying a branch to ckeckout, and to do so within the labeler before issuing git describe.

As a final touch, we've also upgraded the labeller to support dynamic parameters, so the name of the release branch could be specified dynamically when launching the build. The updated labeller is available at its Gitub project .

Git tag labeller plugin for CCNET

When implementing the basic Git workflow described in my previous post, we needed a way to read the last version tag and other related info and pack it as the "build label" within CruiseControl.Net, the integration platform we use.


More precisely, we needed a valid version identifier to be built in two different scenarios:

• Release builds: take the release tag from Git (i.e. "v1.0.4.0"), skip the "v" prefix and return the rest as the version ID.
• QA builds: we do not tag each QA build, so we need to take into account the last tag and the number of commits ahead that, then merge them into something like "1.0.4.105" meaning "5 commits ahead of release 1.0.4.0".  Why 105 and not 5?  Well, we are reserving a block of  numbers (1.0.4.1 - 1.0.4.100) to accommodate eventual  production fixes on a dedicated release branch.

Enter Git tag labeller plugin for CCNet - we built a plugin to be used as a block in a CCNet configuration script and posted it on GitHub, you can find it here.

Besides the functionality we needed, we added a couple of features some one else may use, like a simple concatenation of the existing git tag with the commits ahead count; i.e. "ReleaseCandidate.6".

See the GitHub project for the most up-to-date documentation and code.