Adding Hudson and SVN revision number into Grails application properties

Wow, it's been absolute ages since I last posted an entry here. Oh well, better late than never. In looking for an excuse to post something, I thought I'd add the strategy I came up with to incorporate both the Hudson build number and our SVN revision number into our Grails application.properties. From that line you can tell, obviously, we use Hudson for our build automation.

This build number insertion approach enables us to easily identify from both a test deployment or a customer deployment which Hudson build was used, and which SVN revision number was used simply by looking at the app.version that I show in the footer.gsp of our app.

To do this is fairly simple. It requires 3 simple steps including 2 changes to your build.xml file that Grails generates for you.

1. In my project files, my application.properties looks as follows:
   
   

   app.version=3.3

   
   ... or whatever major minor version your app is on. Ours is currently at 3.3.
   
   
2. In my build.xml file I added a task:
   
   

   <target name="buildnumber">
   <property environment="env"/>
   <replaceregexp file="${local.dir}/application.properties"
   match="app.version=(.*)"
   replace="app.version=\1.${env.BUILD_NUMBER}.${env.SVN_REVISION}"
   byline="true"/>
   </target>
   

   
   This task is run as a depends of prod.war. ${local.dir} is actually mapped to '.' in my build file properties, so you can always just make it "./application.properties" in the task above.
   
   
3. prod.war task is changed as follows:
   
   

   <target name="prod.war" depends="buildnumber" ...

So what happens is that when Hudson triggers the build, the 'buildnumber' task in 2 above appends both the Hudson build number and the SVN revision number to the app.version number before Grails builds the WAR file.

This way, we know which Hudson build is being used, and which SVN revision was used in that build. This helps us in both QM and out in the wild when a customer reports a problem. Also, with SVN we never have to tag a build because the revision number is the tag. If we need to make bug fix changes we can branch from a revision and we're good to go.

Localhost suddenly broken and I'm blaming Windows Update

Wow, it's been absolute ages since I last posted. SO much has happened since my last post. CentraStage is going very well. We're growing from strength to strength but easy does it nicely.

Anyway, today I just wanted to quickly note a frustration I experienced today. After months of never having any trouble using 'localhost' as a reference to my Tomcat instance, or my local database, 'localhost' suddenly broke. Kaput! Dood! Every time I tried to use localhost the connection was refused. I Googled this and found a variety of potential reasons, none of them all that encouraging since they had very little to do with anything I used on my machine.

A number of posts referred to entries in the hosts file, but these referred to the /etc/hosts file in Unix/Linux-land. Nevertheless, there is a Windows hosts file buried in %windir%\system32\drivers\etc\hosts. So I looked at that file and there was a single entry:

::1 localhost

Many Google posts had another line as a translation of localhost to 127.0.0.1. What was peculiar is that if I used 127.0.0.1 in place of localhost in my apps, it would work fine. So something seemed wrong with my translation. Yet I had done nothing that should have affected this, and the hosts file itself was last changed in September 2006.

I conferred with a colleague who indicated that he had the two entries as I'd seen in some of the Google posts, but both of his entries were commented out. After trying numerous things, including attempting to roll back to a system restore point prior to my most recent Windows Update (which as far as I'm concerned is when things started misbehaving) - an exercise that was futile since all my restore points are benign (Windows says there was a problem rolling back and that no changes were made) - I decided to have a go at changing the hosts file.

Look no further than: http://support.microsoft.com/default.aspx?scid=kb;en-us;923947 for how to do this. So I commented out the one line that referred to localhost, restarted my app, and baddabing, baddaboom - it all just worked.

So I have no idea what caused this problem, but needless to say it disabled me for the day. I still strongly suspect the Windows Update that ran this morning, but I'll never really know. But it's fixed now thank goodness for that!