- Each computer has an user called
hudsonand a group called
hudson. All computers use the same UID and GID. (If you have access to NIS, this can be done more easily.) This is not a Hudson requirement, but it makes the slave management easier.
- On each computer,
/var/hudsondirectory is set as the home directory of user
hudson. Again, this is not a hard requirement, but having the same directory layout makes things easier to maintain.
- All machines run SSHD. Windows slaves run cygwin sshd.
- All machines have ntp client installed, and synchronize clock regularly with the same NTP server.
/var/hudsonhave all the build tools beneath it --- a few versions of Ant, Maven, and JDKs. JDKs are native programs, so I have JDK copys copies for all the architectures I need. The directory structure looks like this:
/var/hudson +- .ssh +- bin | +- slave (more about this below) +- workspace (hudson creates this file and store all data files inside) +- tools +- ant-1.5 +- ant-1.6 +- maven-1.0.2 +- maven-2.0 +- java-1.4 -> native/java-1.4 (symlink) +- java-1.5 -> native/java-1.5 (symlink) +- native -> solaris-sparcv9 (symlink; different on each computer) +- solaris-sparcv9 | +- java-1.4 | +- java-1.5 +- linux-amd64 +- java-1.4 +- java-1.5
/var/hudson/.sshhas private/public key and
authorized_keysso that a master can execute programs on slaves through ssh, by using public key authentication.
- On master, I have a little shell script that uses rsync to synchronize master's
/var/hudsonto slaves (except
/var/hudson/workspace) I use this to replicate tools on all slaves.
/var/hudson/bin/launch-slaveis a shell script that Hudson uses to execute jobs remotely. This shell script sets up
PATHand a few other things before launching
- Finally all computers have other standard build tools like
cvsinstalled and available in PATH.
Typically, you start with a master-only installation and then much later you add slaves as your projcets projects grow. When you enable the master/slave mode, Hudson automatically configures all your existing projects to stick to the master node. This is a precaution to avoid disturbing existing projects, since most likely you won't be able to configure slaves correctly without trial and error. After you configure slaves successfully, you need to individually configure projects to let them roam freely. This is tedious, but it allows you to work on one project at a time.
- Every time Hudson launchs launches a program locally/remotely, it prints out the command line to the log file. So when a remote execution fails, login to the computer that runs the master by using the same user account, and try to run the command from your shell. You tend to solve problems quickly in this way.
- Each slave has a log page showing the communication between the master and the slave agent. This log often shows error reports.
- Feel free to send your trouble to