THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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
The Struts 2.x build is very similar to the Struts 1.x builds. There is added logic for deploying SNAPSHOT artifacts and pushing nightly builds from the assembly module. Let's take a look at the configuration -
The batch task setup for Hudson allows for tasks to be executed as part of a build. The tasks configured here are the sort of things that would generally be run manually. This facility allows tasks to be run in a way that is tracked. Adding tasks to this section of the configuration does not mark the tasks to be run automatically, it simply makes them available. Further down in the configuration, the tasks are flagged to be run after the build is complete.
The first batch task listed will log into people.apache.org and add the group writeable flag to all the files that this build just deploys. Hudson logs into people.apache.org as 'wesw' because the public ssh key for the hudson user account on the hudson zone is setup in the 'wesw' account on people.apache.org. Since Hudson logs into people.apache.org as 'wesw,' when SNAPSHOT artifacts are deployed, they are owned by 'wesw.' The umask is setup on people.apache.org so that files are created with group read but not group write permissions. Changing the permissions allows other struts developers (other than 'wesw') to make changes or manually push the files from somewhere other than Hudson.
The second batch task publishes the nightly files by calling a shell script. The contents of the script are listed below -
| Panel | ||
|---|---|---|
| ||
#!/bin/bash TODAY=`date +%Y%m%d%H%M` for zip in $(ls struts2/assembly/target/assembly/out/*.zip); ssh $TARGET_BASE "chmod g+w $TARGET_DIR/*.zip" |
The logic in the shell script is copied quite a bit from James Mitchell's previous nightly script (thank James!). Currently, there is no logic for removing old files. I will add this as soon as more than 5 copies of the assembly zips have been published. This script is group writeable, so other developers can make changes to it. If Wes Wannemacher is unavailable, then this script can be copied to another location on the hudson zone and manipulated as necessary. Then, the struts2 job configuration can be updated as necessary.
Much of the struts2 job's configuration is identical, or only slightly modified (such as pointing to the struts2 folder in SVN) from the struts1 configuration. The next significant differences come up in the Post-build section. Let's take a look -
The struts2 job performs the maven clean and install goals, but then leaves the snapshot deployments up to Hudson as a post-build action. This is done because this is a multi-module build. If the deploy goal were specified as part of the build, it is possible that some artifacts would be deployed and other would not. Having hudson do deployments as a post-build action means that deployment will happen as a separate step after the builds complete successfully. Moving along -
The tasks configured above are specified here to run as post-build actions. Although these tasks are tied to this build, and will happen with each successful build, they can also be launched manually from within Hudson. The Hudson job configuration allows you to specify tasks from any job, so it would be prudent to make sure scripts and commands operate in a way that they could be launched from any other Apache Struts build job (such as reusing the nightly-2.x.sh script to publish struts1 zips as well). Coming soon, I have to get some sleep!