Page History

...

The "local module directory" option allows us to specify a name for the folder that gets checked out. Otherwise, it would be named "trunk," so I went ahead and called it struts1. By checking the "use update" option, the builds will go faster. The downside is that unversioned files may stick around in the workspace. To remedy this, I run the "clean" goal as part of the build. I also leave it up to Hudson to try to figure out which repository browser is in place. Moving along -

...

This screencap shows the triggers that can cause Hudson to launch a build. The first option, when SNAPSHOT dependencies are built, is likely never to launch a build in our case. Currently, we are not using any external SNAPSHOT dependencies, and as far as I know, Hudson would only know if a SNAPSHOT dependency is built if this instance of Hudson builds it. I am leaving it checked as a just-in-case type of trigger. The second option checked, Poll SCM, is likely to be the trigger that fires our builds. The current schedule "30 9 * * *" is very similar to CRON. The struts1 build is scheduled to check SVN every day at 9:30AM. If it detects a change since the last build, a full build will begin. Moving along -

Image Added

The Maven configuration is straightforward. The Heap and PermGen settings were added because I have had problems on Linux building without them. We do not use a private repository because we all of our external dependencies are non-SNAPSHOT. The modules are not currently built in parallel, but if the length of time to build becomes an issue, we could try turning this one. Moving along -

Image Added

None of these build settings are currently enabled. In the next few days I will try to enable the notification emails so that successful or failed builds are sent to dev@struts.apache.org. Currently no emails are sent because I have been making frequent changes to the build configurations. Moving along -

Image Added

The build lock is setup so that we only perform one struts build at a time on Hudson. Part of this is based on wanting to be a good guest on the Apache Hudson instance, but this lock may also become necessary if we begin building sandbox artifacts.

The struts1 build is an easy-to-follow setup and has run a few times without problems. Next, we will take a look at the struts2 build which is very similar but has configuration added to handle deployment of SNAPSHOTs and the zips from the assembly module.

Build Setup - Struts 2.x

Coming soon, I have to get some sleep!