renaming all 'hudson' to 'jenkins'

Gemfile

@@ -1,4 +1,4 @@
 source "http://rubygems.org"
 
-# Specify your gem's dependencies in engineyard-hudson.gemspec
+# Specify your gem's dependencies in engineyard-jenkins.gemspec
 gemspec

Gemfile.lock

@@ -1,9 +1,9 @@
 PATH
   remote: .
   specs:
-    engineyard-hudson (0.3.2)
-      engineyard (~> 1.3.4)
-      hudson (~> 0.5.0)
+    engineyard-jenkins (0.3.2)
+      engineyard (~> 1.3.17)
+      jenkins (~> 0.6.2)
       thor (~> 0.14.6)
 
 GEM
@@ -39,17 +39,16 @@ GEM
     hpricot (0.8.4)
     httparty (0.6.1)
       crack (= 0.1.8)
-    hudson (0.5.0)
-      builder (~> 2.1.2)
+    jenkins (0.6.2)
+      builder (>= 2.1.2)
       hpricot
       httparty (~> 0.6.1)
       term-ansicolor (>= 1.0.4)
       thor (~> 0.14.2)
-      yajl-ruby (>= 0.7.6)
     json (1.4.6)
     json_pure (1.5.1)
     mime-types (1.16)
-    net-ssh (2.1.3)
+    net-ssh (2.1.4)
     open4 (1.0.1)
     rack (1.2.1)
     rake (0.8.7)
@@ -71,15 +70,14 @@ GEM
     term-ansicolor (1.0.5)
     thor (0.14.6)
     tilt (1.2.2)
-    yajl-ruby (0.8.1)
 
 PLATFORMS
   ruby
 
 DEPENDENCIES
   awesome_print
   cucumber (~> 0.9.4)
-  engineyard-hudson!
+  engineyard-jenkins!
   fakeweb (~> 1.3.0)
   json (~> 1.4.0)
   open4

History.md

@@ -7,14 +7,14 @@
 ## 0.3.1 - 2010-12-1
 
 * install_server
-  * Updates the default host for `hudson` CLI to newly created server
-  * Explicitly set $HOME/$USER so Hudson/Java has access to .gitconfig
+  * Updates the default host for `jenkins` CLI to newly created server
+  * Explicitly set $HOME/$USER so Jenkins/Java has access to .gitconfig
 
 ## 0.3.0 - 2010-11-24
 
 * Renamed task 'server' => 'install_server'
-* install_server does the complete job of setup/installation of Hudson into an environment on AppCloud
-* install_server can take --environment/--account options OR auto-discover which environment to install Hudson into
+* install_server does the complete job of setup/installation of Jenkins into an environment on AppCloud
+* install_server can take --environment/--account options OR auto-discover which environment to install Jenkins into
 
 
 ## 0.2.0 - 2010-10-30
@@ -23,5 +23,5 @@
 
 ## 0.1.0 - 2010-10-30
 
-* Initial 'ey-hudson install .' command
-* 'ey-hudson server' shows 'Coming soon'
+* Initial 'ey-jenkins install .' command
+* 'ey-jenkins server' shows 'Coming soon'

README.md

@@ -6,50 +6,50 @@ You're developing on OS X or Windows, deploying to Engine Yard AppCloud (Gentoo/
 
 It's a nightmare. It was for me. 
 
-But now, [Hudson CI](http://hudson-ci.org/), the [hudson](http://github.com/cowboyd/hudson.rb) CLI project, and **engineyard-hudson** now make CI easier to do than not to for Engine Yard AppCloud users.
+But now, [Jenkins CI](http://jenkins-ci.org/), the [jenkins](http://github.com/cowboyd/jenkins.rb) CLI project, and **engineyard-jenkins** now make CI easier to do than not to for Engine Yard AppCloud users.
 
 And here's some logos:
 
 <img src="http://img.skitch.com/20101103-gcq2turgih14rjdqatt1kjkd6u.png">
 
 ## Installation
 
-    gem install engineyard-hudson
+    gem install engineyard-jenkins
 
-This will also install the `hudson` CLI to interact with your Hudson CI from the command line.
+This will also install the `jenkins` CLI to interact with your Jenkins CI from the command line.
 
 ## Hosting on Engine Yard AppCloud
 
-Using Engine Yard AppCloud "Quick Start" wizard, create an application with Git Repo `git://github.com/engineyard/hudson_server.git` (options: rails 3, passenger), 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). 
+Using Engine Yard AppCloud "Quick Start" wizard, create an application with Git Repo `git://github.com/engineyard/jenkins_server.git` (options: rails 3, passenger), and add your own SSH keys. This will create an environment called `jenkins_server_production`. Boot the environment as a Single instance (or Custom cluster with a single instance). 
 
-Optionally, though it is quite pretty, deploy/ship the hudson_server application and visit the HTTP link to see the remaining "Almost there..." instructions.
+Optionally, though it is quite pretty, deploy/ship the jenkins_server application and visit the HTTP link to see the remaining "Almost there..." instructions.
 
-Finally, install Hudson CI and rebuild the environment:
+Finally, install Jenkins CI and rebuild the environment:
 
-    $ ey-hudson install_server
+    $ ey-jenkins install_server
 
-When this completes, visit the URL or refresh the "Almost there..." page to see your Hudson CI server.
+When this completes, visit the URL or refresh the "Almost there..." page to see your Jenkins CI server.
 
-Using the `hudson list` CLI task you can also test there is a working server with no jobs:
+Using the `jenkins list` CLI task you can also test there is a working server with no jobs:
 
-*For the Hudson slaves' configuration, you'll need:*
+*For the Jenkins slaves' configuration, you'll need:*
 
-The `hudson_server_production` instance public key:
+The `jenkins_server_production` instance public key:
 
-    $ ey ssh -e hudson_server_production
+    $ ey ssh -e jenkins_server_production
     # cat /home/deploy/.ssh/id_rsa.pub
 
-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.
+Do those steps, copy down the configuration and you're done! Now, you either visit your Jenkins CI site or use `jenkins list` to see the status of your projects being tested.
 
 ## Hosting elsewhere
 
-Hosting Hudson CI on Engine Yard AppCloud is optional; yet delightfully simple. Hudson CI can be hosted anywhere.
+Hosting Jenkins CI on Engine Yard AppCloud is optional; yet delightfully simple. Jenkins 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:
+If you host your Jenkins CI elsewhere then you need the following information about your Jenkins CI environment to be able to add EngineYard AppCloud instances as Jenkins 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`)
+* Jenkins CI public host & port
+* Jenkins CI's user's public key (probably at `/home/deploy/.ssh/id_rsa.pub`)
+* Jenkins CI's user's private key path (probably `/home/deploy/.ssh/id_rsa`)
 
 ## Running your CI tests on Engine Yard AppCloud
 
@@ -66,43 +66,43 @@ In the Engine Yard AppCloud UI, create another environment that matches the prod
 Now, in just a few steps and you will have your applications' tests running in an environment that matches your production environment:
 
     $ cd /my/project
-    $ ey-hudson install .
+    $ ey-jenkins install .
 
-Now edit `cookbooks/hudson_slave/attributes/default.rb` to set up the Hudson CI instance details gathered above.
+Now edit `cookbooks/jenkins_slave/attributes/default.rb` to set up the Jenkins CI instance details gathered above.
 
     $ ey recipes upload -e ci_demo_app_ci
     $ ey recipes apply -e ci_demo_app_ci
 
-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!
+Boot your `ci_demo_app_ci` environment, visit your Jenkins 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
+At any time from the command line you can use `jenkins list` to see the status of your jobs
 
 ## 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 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.
+* Do not use your production environment as your Jenkins CI slave. There are no guarantees what will happen. I expect bad things.
+* You must name your CI environments with a suffix of `_ci` or `_jenkins_slave`.
+* You should not name any other environments with a suffix of `_ci` or `_jenkins_slave`; lest they offer themselves to your Jenkins 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`).
+For example, note the naming convention of the two CI environments below (one ends in `_jenkins_slave` and the other `_ci`).
 
 <img src="http://img.skitch.com/20101031-dxnk7hbn32yce9rum1ctwjwt1w.png" style="width: 100%">
 
 ## 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:
+When you boot your Engine Yard AppCloud CI environments, each resulting EC2 instance executes a special "jenkins_slave" recipe (see `cookbooks/jenkins_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".
+* Adds this instance to your Jenkins CI server as a slave
+* Adds each Rails/Rack application for the AppCloud environment into your Jenkins CI as a "job".
 * Commences the first build of any newly added job.
 
-If your CI instances have already been booted and you re-apply the recipes over and over (`ey recipes apply`), nothing good or bad will happen. The instances will stay registered as slaves and the applications will stay registered as Hudson CI jobs.
+If your CI instances have already been booted and you re-apply the recipes over and over (`ey recipes apply`), nothing good or bad will happen. The instances will stay registered as slaves and the applications will stay registered as Jenkins CI jobs.
 
-If a new application is on the instance, then a new job will be created on Hudson CI.
+If a new application is on the instance, then a new job will be created on Jenkins CI.
 
-To delete a job from Hudson CI, you should also delete it from your AppCloud CI environment to ensure it isn't re-added the next time you re-apply or re-build or terminate/boot your CI environment. (To delete a job, use the Hudson CI UI or `hudson remove APP-NAME` from the CLI.)
+To delete a job from Jenkins CI, you should also delete it from your AppCloud CI environment to ensure it isn't re-added the next time you re-apply or re-build or terminate/boot your CI environment. (To delete a job, use the Jenkins CI UI or `jenkins remove APP-NAME` from the CLI.)
 
-In essence, to add new Rails/Rack applications into your Hudson CI server you:
+In essence, to add new Rails/Rack applications into your Jenkins CI server you:
 
 * Add them to one of your Engine Yard AppCloud CI environments (the one that matches the production environment where the application will be hosted)
 * Rebuild the environment or re-apply the custom recipes (`ey recipes apply`)
@@ -113,23 +113,23 @@ Thusly demonstrated below: the application/job "ci_demo_app" is in the middle of
 
 <img src="http://img.skitch.com/20101031-tga2f23wems1acpad1ua41qdmb.png" style="width: 100%">
 
-### Can I add applications/jobs to Hudson CI other ways?
+### Can I add applications/jobs to Jenkins CI other ways?
 
-Yes. There are three simple ways to get Hudson CI to run tests for your application ("create a job to run builds"). Above is the first: all "applications" on the Engine Yard AppCloud CI environment will automatically become Hudson CI jobs. The alternates are:
+Yes. There are three simple ways to get Jenkins CI to run tests for your application ("create a job to run builds"). Above is the first: all "applications" on the Engine Yard AppCloud CI environment will automatically become Jenkins CI jobs. The alternates are:
 
-* Use the `hudson create .` command from the [hudson](http://github.com/cowboyd/hudson.rb) CLI. 
+* Use the `jenkins create .` command from the [jenkins](http://github.com/cowboyd/jenkins.rb) CLI. 
 
 Pass the `--assigned_node xyz` flag to make the project's test be executed on a specific slave node. "xyz" is the name of another application on your AppCloud account; your tests will be executed on the same instance, with the same version of Ruby etc.
 
-* Use the Hudson CI UI to create a new job. As above, you can make sure the tests are run on a specific Engine Yard AppCloud instance by setting the assigned node label to be the same as another AppCloud application in your account that is being tested.
+* Use the Jenkins CI UI to create a new job. As above, you can make sure the tests are run on a specific Engine Yard AppCloud instance by setting the assigned node label to be the same as another AppCloud application in your account that is being tested.
 
-Specifically, Hudson CI uses "labels" to match jobs to slaves. A common example usage is to label a Windows slave as "windows". A job could then be restricted to only running on slaves with label "windows". We are using this same mechanism.
+Specifically, Jenkins CI uses "labels" to match jobs to slaves. A common example usage is to label a Windows slave as "windows". A job could then be restricted to only running on slaves with label "windows". We are using this same mechanism.
 
 ## Automatically triggering job builds
 
-In Hudson CI, a "job" is one of your projects. Each time it runs your tests, it is called a "build".
+In Jenkins CI, a "job" is one of your projects. Each time it runs your tests, it is called a "build".
 
-It is often desirable to have your SCM trigger Hudson CI to run your job build whenever you push new code.
+It is often desirable to have your SCM trigger Jenkins CI to run your job build whenever you push new code.
 
 ### GitHub Service Hooks
 
@@ -147,9 +147,9 @@ You can also use the "Test Hook" link to test this is wired up correctly.
 
 ### CLI
 
-Using the `hudson` CLI:
+Using the `jenkins` CLI:
 
-    hudson build path/to/APP-NAME
+    jenkins build path/to/APP-NAME
 
 ### Curl
 
@@ -160,7 +160,7 @@ You are triggering the build via a GET call to an URL endpoint. So you can also
 ## Contributions
 
 * Dr Nic Williams ([drnic](http://github.com/drnic))
-* Bodaniel Jeanes ([bjeanes](http://github.com/bjeanes)) - initial chef recipes for [Hudson server + slave](http://github.com/bjeanes/ey-cloud-recipes)
+* Bodaniel Jeanes ([bjeanes](http://github.com/bjeanes)) - initial chef recipes for [Jenkins server + slave](http://github.com/bjeanes/ey-cloud-recipes)
 
 ## License
 

bin/ey-jenkins

@@ -0,0 +1,7 @@
+#!/usr/bin/env ruby
+
+$:.unshift(File.expand_path(File.dirname(__FILE__) + "/../lib"))
+require 'engineyard-jenkins'
+require 'engineyard-jenkins/cli'
+
+Engineyard::Jenkins::CLI.start

engineyard-hudson.gemspec → engineyard-jenkins.gemspec

@@ -1,25 +1,25 @@
 # -*- encoding: utf-8 -*-
 
 Gem::Specification.new do |s|
-  s.name        = "engineyard-hudson"
+  s.name        = "engineyard-jenkins"
   s.version     = '0.3.2'
   s.platform    = Gem::Platform::RUBY
   s.authors     = ["Dr Nic Williams"]
   s.email       = ["drnicwilliams@gmail.com"]
-  s.homepage    = "http://github.com/engineyard/engineyard-hudson"
-  s.summary     = %q{Easier to do CI than not to. Use Hudson CI with Engine Yard AppCloud.}
+  s.homepage    = "http://github.com/engineyard/engineyard-jenkins"
+  s.summary     = %q{Easier to do CI than not to. Use Jenkins CI with Engine Yard AppCloud.}
   s.description = %q{Run your continuous integration (CI) tests against your Engine Yard AppCloud environments - the exact same configuration you are using in production!}
 
-  s.rubyforge_project = "engineyard-hudson"
+  s.rubyforge_project = "engineyard-jenkins"
 
   s.files         = `git ls-files`.split("\n")
   s.test_files    = `git ls-files -- {test,spec,features}/*`.split("\n")
   s.executables   = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
   s.require_paths = ["lib"]
 
   s.add_dependency("thor", ["~> 0.14.6"])
-  s.add_dependency("engineyard", ["~> 1.3.4"])
-  s.add_dependency("hudson", ["~> 0.5.0"])
+  s.add_dependency("engineyard", ["~> 1.3.17"])
+  s.add_dependency("jenkins", ["~> 0.6.2"])
 
   s.add_development_dependency("rake", ["~> 0.8.7"])
   s.add_development_dependency("cucumber", ["~> 0.9.4"])