I recently setup a Hudson continuous integration server for our main development at Escent. Part of that project is a Ruby on Rails web app using Rails 3. I had trouble getting the existing documentation to work for me, possibly because it was designed for Rails 2. I ended using a Gem written by Nathan Humbert to generate the code coverage information. I include a brief description of what I did here in case it is useful to anyone else.
Hudson needs both the Hudson Ruby plugin and the Hudson Ruby Metrics plugin. To add the plugins from the Hudson dashboard, click “Manage Hudson”, then “Manage Plugins”. From the Plugin Manager page, click the “Available” tab, and select the check boxes for the plugins you want. You may also want to select the plugin for your SCM software. Subversion is included by default, but we are using Mercurial, so I also checked the “Hudson Mercurial Plugin” box.
Click the “Install” button at the bottom of the page after you have selected all the plugins you want, and return to the Hudson Dashboard.
We will be using the “rails_code_qa” gem to measure code coverage. to make sure it is in your project, add the following to the project’s Gemfile.
group :development, :test do gem "rails_code_qa" end
Configuring the Build
Starting from the Hudson dashboard, click “New Job” to create a new job for your Rails 3 project. Name the job in the “Job name” box, check the “Build a free-style software project”, and click OK to continue.
The first section is pretty straightforward. You can optionally add a description for you project, configure how many builds to keep, etc. I set our configuration to discard builds after seven days and accepted all the other default options, then skipped the “Advanced Project Options” section.
In the “Source Code Management” section configure this project to access your SCM.
In the “Build Triggers” section you can set the conditions for starting a build. I checked “Poll SCM” and set the schedule to:
*/1 * * * *
So that Hudson will check for updates to the SCM every minute. Once per minute is probably overkill, but for testing purposes, it made it easier to see if Hudson was working. I’ll probably back it off to three or five minutes at some point, to cut back on unnecessary polling.
The “Build” section is where things start to get interesting. Each time Hudson starts a build of your code, it automatically pulls a source tree from the SCM and runs the build commands from the top-level directory of your source tree. The commands “Build” section lets you specify a sequence of commands to be run in a number of different forms.
First, click “Add build step” and select “Execute shell”. In the “command” box that appears type:
to prepare your build environment. Click “Add build step” again, but this time select “Invoke Rake”. I accepted the Default version and in the task box entered:
db:create db:migrate test rcqa
You could just as well add rake to the list of shell commands.
In the “Post-build Actions” section, check the “Publish Rails stats report” and “Publish Rcov report” boxes. The “Rcov report directory” points to the HTML coverage report from rcov. Unfortunately, rails_code_qa does not have an option to give coverage for all the unit tests. It splits results into coverage/units and coverage/functionals directories. For now I am using coverage/units.
Modifying rails_code_qa to put all the results into one directory is trivial, but I still have to figure out how to make it get included in the project. When I figure out the magic rails/rake is doing to run things, I’ll update my Hudson config.