A poor man's Ant build number incrementer

Note: this was originally posted November 17, 2009 on my old blog.

Our situation: our build server uses Ant to automatically get the latest versions of the source files, build the application and deploy it.  A build number is updated in a properties file, but we lost the ability to check that file back into source control. (no write access for build user to source control server). This means the build number, say 500, is always incremented to 501, packaged into the war file, and sent out on the server.  The next night, another automated build kicks off and the properties file is retrieved with the current build number set at 500.  So the build process dutifully adds one to it, builds and packages the application and sends it off to the server with the build number at 501.  Again.

We needed a way to increment the build number to accurately reflect that a new build is generated and put out on the server - this helps not only to keep tabs on how many times we build the application, but the build number is also used as a random salt in the request parameters to prevent caching issues with browsers.


The workaround below will pseudo-increment the build number based on a "build epoch" - the same way time is kept on unix-like systems.  Note the enclosing target and project tags have been omitted.

  <property name="build.epoch"          value="20090101"/>

  <property name="todays.date"          value="${DSTAMP}"/>

  <propertyfile file="${file.version.properties}">

    <entry key="system.build.number"    value="${todays.date}"/>

    <entry key="system.build.number"

      value="${build.epoch}" type="int" operation="-" pattern="0"/>

  </propertyfile>

In a nutshell: define the build epoch property as a certain date in the past.  The property file then sets the build number to today's date, and then immediately does a subtraction operation using the build epoch.  The dates (in yyyyMMDD format) are treated as integers and you get a different build number for each day.  It's not a true increment (on month boundaries the next number jumps up by about 70) and there is only per-day granularity, but... it works.

There must be tons of ways to avoid the whole problem in the first place, with so many opportunities to "do it the right way first".  While working on this setup, I noticed two thoughts flitting about in a certain echo chamber: "it's amazing"... and moments later: "it's asinine".  This is just how it turned out.