This is a quick post to describe the steps involved with getting Hudson to deploy a Grails application to a remote Tomcat server.

Tomcat
First up you’ll need to ensure that Tomcat has the manager application installed (e.g. on Debian Lenny the tomcat5.5-admin package on stable) and that $TOMCAT_HOME/conf/tomcat-users.xml has been configured with a manager user e.g.

<tomcat-users>
<user name="admin" password="top_secret_password" roles="admin,manager" />
</tomcat-users>

Note: You can also digest the password & configure the realm to use digest passwords…
Update: see this post.

Hudson
Back in Hudson, you’ll need to install the Deploy plugin.
This follows the same process that we covered in part 2 of this series (we’ll omit the screenshots this time):

1. From the main Hudson dashboard, click on the “Manage Hudson” menu item
2. Click on “Manage plugins”
3. Go to the available tab, find & select Deploy, click on the install button.
4. When the plugin has downloaded and installed, you will need to restart Hudson (you can use the button provided).
   

In your Grails job, we need to instruct the Grails builder to package a war file, but first we’ll set the Grails application version number using the Hudson build number for traceability.

1. Set the version number using a Hudson variable:
   
   

   “set-version 1.0.0.${env['BUILD_NUMBER']}”

2. Build a war (e.g. for a prod war named ggug.war):
   
   

   “prod war ggug.war”

The double quotes are required to group the arguments appropriately.

Finally, we’ll instruct Hudson to deploy to a ‘remote’ Tomcat server:

Tips
I’ve used this a lot for automated deployments to pre-production environments (in conjunction with the Grails Autobase plugin). However, for live deployments that require more control I’d typically use the SCP plugin instead and then manually invoke a deployment script (or handle through a configuration management tool e.g. Puppet – see their post on war deployment).

Also, I’ve tended to split the compilation/testing & deployment into two Hudson jobs – this is to separate deployment issues (e.g. Tomcat out of permgen space) from compilation or automated testing failures. If you do this, you’ll probably want the Hudson Next Build Number plugin.