Continuous Integration with Hudson on Glassfish

Continuous Integration is a process that allows software to be built and tested on a frequent basis. There are many tools available for performing Continuous Integration - one of which is Hudson. Hudson allows automated builds to be performed against Java source code and is able to check out code from either Subversion or CVS before performing builds.

Installing Hudson

Installing Hudson is a very trivial process.

After completing the deployment of Hudson, you can access it through the browser by going to

http://localhost:8080/hudson

This presents the main Hudson Dashboard. From here, you can create a new job by selecting the "New Job" link at the top left of the page.

On this screen, you enter a project name and then press the "OK" button to be presented with a screen similar to the following allowing the job to be further defined.

On tes where Hudson will perform its builds. As the application makes extensive use of this, its necessary to set it before starting Glassfish.

After configuring this environment variable, Glassfish can be started and Hudson deployed. Deploying Hudson can be either done by dropping the war into the Glasfish autodeploy directory, or by using the deploy facilities of the Glassfish administration console as shown in the picture below.

After completing the deployment of Hudson, you can access it through the browser by going to

http://localhost:8080/hudson

This presents the main Hudson Dashboard. From here, you can create a new job by selecting the "New Job" link at the top left of the page.

On this screen, you enter a project name and then press the "OK" button to be presented with a screen similar to the following allowing the job to be further defined.

On this screen, you can specify where the source is to be obtained from (either CVS or Subversion). For both of these, you can specify connection details to allow Hudson to obtain the latest code from the SCM before the build process is started.

After specifying which SCM repository to get source from, Hudson requires you to specify how the project will be built. This can be done by performing a shell command on Unix based OS's, by running a batch command on Windows, or by invoking one or more ant targets. If you choose to run an ant target, then you can specify any necessary ant parameters.

You can also specify when the project will be built. Hudson allows you to specify a time period for it to poll the SCM. If Hudson detects and changes to the source after a polling interval, a build will be triggered. It is also possible to specify that builds are performed periodically, for example always build at 2 am.

If you are integrating with Subversion, you can set up a post-commit hook to start the build. This is achieved by creating a post-commit batch/shell script within the Subversion repository. Witrhin the script, it is necessary to issue a wget command to trigger a build.

wget -o /dev/null http://YOURHOST/hudson/job/PROJECTNAME/build

Hudson has several further parameters that can be used to control the job, such as emailing after a build or archiving build artifacts - these can be turned on as and when necessary.

Thats about all there is to creating a job within Hudson and configuring it to automatically build your projects.

Monitoring Builds

After creating a project, the Hudson console shows all the projects that you have configured and their current build status. It shows the last successful build, the last failed build and how long the build took for each job. For each of there, an RSS feed is available so you can hook this up to your favourite RSS aggregator and get details of every build that is performed. For each build, you can get details of what files were edited, by who and also see the console output from the build process.

 

Discuss this post here.