README.md in engineyard-hudson-0.3.0 vs README.md in engineyard-hudson-0.3.1
- old
+ new
@@ -14,66 +14,46 @@
## Installation
gem install engineyard-hudson
-You might also like the `hudson` CLI to play with your Hudson CI from the command line:
+This will also install the `hudson` CLI to interact with your Hudson CI from the command line.
- gem install hudson
+## Hosting on Engine Yard AppCloud
-## Assumptions
+Using Engine Yard AppCloud "Quick Start" wizard, create an application with Git Repo `git://github.com/engineyard/hudson_server.git`, and add your own SSH keys. This will create an environment called `hudson_server_production`. Boot the environment as a Single instance (or Custom cluster with a single instance).
-It is assumed you are familiar with the [engineyard](http://github.com/engineyard/engineyard) CLI gem.
+Optionally, though it is quite pretty, deploy/ship the hudson_server application and visit the HTTP link to see the remaining "Almost there..." instructions.
-You **do not** need to be familiar with custom chef recipes. Just follow the simple commands. Easy peasy.
+Finally, install Hudson CI and rebuild the environment:
-## Warning (aka TODO list)
+ $ ey-hudson install_server
-In the very first release of `engineyard-hudson`:
+When this completes, visit the URL or refresh the "Almost there..." page to see your Hudson CI server.
-* There is no support for authentication/authorization of Hudson CI. It _will_ use the deploy keys already installed on your AppCloud instance, as described in engineyard-serverside [#set_up_git_ssh](http://github.com/engineyard/engineyard-serverside/blob/master/lib/engineyard-serverside/strategies/git.rb#L106-134)
-* No mail server configured for Hudson CI build failure notifications.
+Using the `hudson list` CLI task you can also test there is a working server with no jobs:
-## Hosting Hudson CI
-
-Hosting Hudson CI on Engine Yard AppCloud is optional; yet delightfully simple. Hudson CI can be hosted anywhere.
-
-### Hosting on Engine Yard AppCloud
-
-Using Engine Yard AppCloud "Quick Start" wizard, create an application with Git Repo `git://github.com/drnic/ci_demo_app.git` (any arbitrary rails/rack application), and add your own SSH keys. Name the environment `hudson` (or similar) and boot it as a Single instance (or Custom cluster with a single instance).
-
-Just a few steps and you will have your own Hudson CI:
-
- $ mkdir hudson_server
- $ cd hudson_server
- $ ey-hudson server . --plugins 'googleanalytics,chucknorris'
- $ ey recipes upload -e hudson
- $ ey recipes apply -e hudson
-
*For the Hudson slaves' configuration, you'll need:*
-The `hudson` instance public key:
+The `hudson_server_production` instance public key:
- $ ey ssh -e hudson
- $ cat /home/deploy/.ssh/id_rsa.pub
+ $ ey ssh -e hudson_server_production
+ # cat /home/deploy/.ssh/id_rsa.pub
-The `hudson` instance URI:
-
- $ sudo ruby -rubygems -e "require 'json'; puts JSON.parse(File.read('/etc/chef/dna.json'))['engineyard']['environment']['instances'].first['public_hostname']"
-
-
Do those steps, copy down the configuration and you're done! Now, you either visit your Hudson CI site or use `hudson list` to see the status of your projects being tested.
-### Hosting elsewhere
+## Hosting elsewhere
-You need the following information about your Hudson CI:
+Hosting Hudson CI on Engine Yard AppCloud is optional; yet delightfully simple. Hudson CI can be hosted anywhere.
+If you host your Hudson CI elsewhere then you need the following information about your Hudson CI environment to be able to add EngineYard AppCloud instances as Hudson nodes/slaves:
+
* Hudson CI public host & port
* Hudson CI's user's public key (probably at `/home/deploy/.ssh/id_rsa.pub`)
* Hudson CI's user's private key path (probably `/home/deploy/.ssh/id_rsa`)
-## Running your tests in Hudson against Engine Yard AppCloud
+## Running your CI tests on Engine Yard AppCloud
This is the exciting part - ensuring that your CI tests are being run in the same environment as your production applications. In this case, on Engine Yard AppCloud.
It is assumed that you already have a production application environment (might have multiple applications in it):
@@ -95,21 +75,21 @@
Boot your `ci_demo_app_ci` environment, visit your Hudson CI and WOW! jobs have been created, they are already running, and they are doing it upon your `ci_demo_app_ci` environment!
At any time from the command line you can use `hudson list` to see the status of your jobs
-### Conventions/Requirements
+## Conventions/Requirements
* Do not use your production environment as your Hudson CI slave. There are no guarantees what will happen. I expect bad things.
-* You must name your CI environment with a suffix of `_ci` or `_hudson_slave`.
+* You must name your CI environments with a suffix of `_ci` or `_hudson_slave`.
* You should not name any other environments with a suffix of `_ci` or `_hudson_slave`; lest they offer themselves to your Hudson CI as slave nodes.
* Keep your production and CI environments exactly the same. Use the same Ruby implementation/version, same database, and include the same RubyGems and Unix packages. Why? This is the entire point of the exercise: to run your CI tests in the same environment as your production application runs.
For example, note the naming convention of the two CI environments below (one ends in `_hudson_slave` and the other `_ci`).
<img src="http://img.skitch.com/20101031-dxnk7hbn32yce9rum1ctwjwt1w.png" style="width: 100%">
-### What happens?
+## What happens?
When you boot your Engine Yard AppCloud CI environments, each resulting EC2 instance executes a special "hudson_slave" recipe (see `cookbooks/hudson_slave/recipes/default.rb` in your project). This does three things:
* Adds this instance to your Hudson CI server as a slave
* Adds each Rails/Rack application for the AppCloud environment into your Hudson CI as a "job".
\ No newline at end of file