Allow Hudson to start slaves on EC2 on demand, and kill them as they get unused.
With this plugin, if Hudson notices that your build cluster is overloaded, it'll start instances on EC2 and automatically connect them as Hudson slaves. When the load goes down, excessive EC2 instances will be terminated. This set up allows you to maintain a small in-house cluster, then spill the spiky build/test loads into EC2.

Usage

First, go to EC2 and sign up for the service. Then enter the username/password information. Because of the way EC2 works, you also need to have an RSA private key. If you have already been using EC2 and have your own key, you can paste it here. Otherwise, you can have Hudson generate one. If you let Hudson generate one, you should save this private key in your file system as well, as you'll need this to interactively logon to EC2 instances.

Use "Test Connection" button to verify that Hudson can successfully talk to EC2.

Next, configure AMIs that you want to launch. For this, you need to find the AMI IDs for the OS of your choice. ElasticFox is a good tool for doing that, but there are a number of other ways to do it. Hudson can work with any Unix AMIs. Windows is currently unsupported.

Configuring labels allow Hudson to pick the right AMI to start. For example, if all your existing slaves labeled "solaris" are fully busy and you have more builds that are tied to the "solaris" label, Hudson will start the AMIs that have the "solaris" label.

Init script is the shell script to be run on the newly launched EC2 instance, before Hudson starts launching a slave agent. If the AMI doesn't have Java pre-installed, you need to do so in this script. This is also a good place to install additional packages that you need for your builds and tests.

Configure several AMIs if you need different OS images.

With this setting, your Hudson will automatically start instances when the load goes up, and the instances will be terminated automatically if it's idle for more than 30 mins.

Changelog

Version 1.5 (Nov 20 2009)

• Number of executors wasn't properly persisted (issue #4906)

Version 1.4 (Aug 5 2009)

• Hudson does several retries on SSH logins to give sshd extra time to initialize itself (issue #4119)

Version 1.3 (July 27 2009)

• User-data can be now specified to the launching instances (issue #4115)
• # of executors can be now configured (issue #4116)

Version 1.2 (Jun 18 2009)

• Fixed the dependency issue with recent Hudson

Version 1.1 (May 28 2009)

• Re-implemented the instance cap so that it uses AWS API for # of instances to prevent run-away EC2 instances.
• Improved the performance of instance launches
• Fixed a bug where a long init script may cause Hudson to start additional instances.
• If the init script has run once, don't run it again when reconnecting.

Version 1.0

• Initial release