Archive

Archive for the ‘svn’ Category

Stamping QA builds with SVN revision number

December 16, 2006 3 comments

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:


<profiles>
  <profile>
    <id>qabuild</id>
    <build>
      <plugins>
        <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>exec-maven-plugin</artifactId>
          <executions>
            <execution>
              <phase>compile</phase>
              <goals>
                <goal>exec</goal>
              </goals>
            </execution>
          </executions>
          <configuration>
          <!--
            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
            http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/howto.html
            but it is not maintained right now.
          -->
            <executable>${svn.executable}</executable>
            <arguments>
              <argument>info</argument>
              <argument>></argument>
              <argument>target/classes/revision.txt</argument>
            </arguments>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>

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