Home > maven, svn, tech > Stamping QA builds with SVN revision number

Stamping QA builds with SVN revision number

In the project I am working on now, we push newer builds to QA frequently. This is the first project here that uses SVN; we were using CVS before this one. When using CVS we usually TAG the repository before pushing a build to QA; when QA file bugs the TAG number of the build is mentioned. This helps tracking bugs effectively.

SVN puts a unique revision number to every change to the repository – every change to the repository is implictly tagged by the revision number of that changeset. So a better scheme would be to stamp the build with the SVN revision number.

The maven-buildnumber plugin is designed to do exactly this. But unfortunately the plugin is no longer maintained and does not work well. So I devised my own mechanism to get the SVN revision number. Firstly, on my continuous integration build machine (where the QA builds are cut), I installed the svn native client. Then, I added the following section in the POM:

            We are essentially running:
                svn info > target/classes/revision.txt
            The obvious gotchas is that it works only if SVN client is
            installed on the build machine. For now, we can live with
            this restriction. A more complete plugin
            is available at
            but it is not maintained right now.

In the settings.xml file of the build machine, I set the svn.executable property to the location where the svn native client is installed. When the build machine builds out my web application it runs Maven with the ‘qabuild’ profile turned on (mvn -Pqabuild package). When this profile is turned on, the build (after the main classes are compiled) runs the native svn client and outputs the repository version information into a file in the classes directory. This file also gets packaged as part of my web application. In my web application, I read this file and include the revision number as part of the footer in each JSP. If the file cannot be found (i.e. the build was not run with qabuild profile) or if there is some error reading the file my JSP ignores those errors and prints no revision number – that way the developers are not forced to install native SVN client on their local machine (most of us use Smart SVN, which depends on the Java SVN client from tmate.org).

We use the revision number in our bug reports. We plan to enhance our bug tracking tool to have queries based on the revision number field.

Categories: maven, svn, tech
  1. April 25, 2007 at 2:48 pm

    Nice tip! I plan on investigating both the plugin and your approach.

  2. neil
    July 12, 2007 at 3:18 pm

    One thing that confuses me: doesn’t this just grab the revision of the *directory* and not the revision of its contents?

    When I do ‘svn info’ and ‘svn info *’, I get an early revision for when the directory was created, but a later revision for each file inside.

  3. Adrian
    January 28, 2008 at 4:11 pm

    Have you run svn update for the directory before svn info

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: