Distributed builds

compared with
Current by Bob Foster
on Aug 06, 2013 11:46.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (4)

View page history
h2. Have master launch slave agent via ssh
Hudson has a built-in SSH client implementation that it can use to talk to remote sshd and start a slave agent. This is the most convenient and preferred method for Unix slaves, which normally has sshd out-of-the-box. Click Manage Hudson, then Manage Nodes, then click "New Node." In this set up, you'll supply the connection information (the slave host name, user name, and ssh credential). Note that the slave will need the master's public ssh key copied to \~/.ssh/authorized_keys. ([This is a decent howto|http://sial.org/howto/openssh/publickey-auth/] howto|http://inside.mines.edu/~gmurray/HowTo/sshNotes.html] if you need ssh help). Hudson will do the rest of the work by itself, including copying the binary needed for a slave agent, and starting/stopping slaves. If your project has external dependencies (like a special \~/.m2/settings.xml, or a special version of java), you'll need to set that up yourself, though. {color:#ff9900}\[Where is this documented?\]{color}

This is the most convenient set up on Unix.
(The point is that you let Hudson run this command, as Hudson uses this stdin/stdout as the communication channel to the slave agent. Because of this, running this manually from your shell [will do you no good|HUDSON:Launching slave.jar from from console]).
A copy of {{slave.jar}} can be downloaded from {{[http://yourserver:port/hudson/jnlpJars/slave.jar]}} {color:#ff9900}\[This gives a 404 error under 1.339 - see{color} {color:#ff9900}[HUDSON-5239|http://issues.hudson-ci.org/browse/HUDSON-5239]{color}{color:#ff9900}\]{color}. Many people write scripts in such a way that this 160K jar is downloaded during the script, to make sure the consistent version of {{slave.jar}} is always used.
A copy of {{slave.jar}} can be downloaded from {{[http://yourserver:port/jnlpJars/slave.jar]}} . Many people write scripts in such a way that this 160K jar is downloaded during the script, to make sure the consistent version of {{slave.jar}} is always used. The [SSH Slaves|SSH Slaves plugin] plugin does this automatically, so slaves configured using this plugin always use the correct {{slave.jar}}.
{info:title=Updating slave.jar}Technically speaking, in this set up you should update {{slave.jar}} every time you upgrade Hudson to a new version. However, in practice {{slave.jar}} changes infrequently enough that it's also practical not to update until you see a fatal problem in start-up.
{info}Launching slaves this way often requires an additional initial set up on slaves (especially on Windows, where remote login mechanism is not available out of box), but the benefits of this approach is that when the connection goes bad, you can use Hudson's web interface to re-establish the connection.
h1. Running Multiple Slaves on the Same Machine
 It is possible to run multiple slave instances on a Windows machine, and have them installed as separate Windows services so they can start up on system startup. While the correct use of executors largely obviates the need for multiple slave instances on the same machine, there are some unique use cases to consider:
* You want more configurability between the configured nodes. Say you have one node set to be used as much as possible, and the other node do be used only when needed.
* You may have multiple Hudson master installations building different things, and so this configuration would allow you to have slaves for more than one master on the same box. That's right, with Hudson you really can serve two masters.