Ok, that was really annoying. Setting up a new build server just should not take as long as this did.
What is ContinuousBuilder you ask? Good question. If I had not bought the beta-book Rails Recipes, I would never have heard of it. A Google search on the topic brings up… yup, you guessed it, the source code for ContinuousBuilder, and nothing else. ContinuousBuilder is a plugin for Rails, that is a very (very) simple continuous integration implementation. You can install it in your Rails app by using:ruby script/plugin install continuous_builderIf you read the accompanying README.txt, you’ll know about as much as I did when I started. On to the meaty stuff. Couple of things about ContinuousBuilder and Subversion you should know before you start…
- ContinuousBuilder will not send email to you on success. So when everything is working, you get no feedback. And when it is really, really broken, you get… no feedback. This is not good, especially when you are setting up ContinuousBuilder for the first time. And, with a small team, I prefer to get emails for every commit, just so I know the build really is working. The answer was simple. First, in test_build.rake, I added a deliver_success call:
[code lang=”ruby”]
case build.run
when :failed
ContinuousBuilder::Notifier.deliver_failure(build, notice_options)
when :revived
ContinuousBuilder::Notifier.deliver_revival(build, notice_options)
when :broken
ContinuousBuilder::Notifier.deliver_broken(build, notice_options)
when :unchanged, :succesful
# Smile, be happy, it’s all good
ContinuousBuilder::Notifier.deliver_success(build, notice_options)
end
[/code] Then, in the continuous_builder.rb file, under Notifier, I added a success method
[code lang=”ruby”]
def success(build, options, sent_at = Time.now)
@subject = “[#{options[:application_name]}] Build working (##{build.checkout.current_revision})”
@body = [ build.checkout.last_commit_message, build.output ].join(“nn”)
@recipients, @from, @sent_on = options[:recipients], options[:sender], sent_at
end
[/code]
Now I get messages for every commit, good or bad.
- In Subversion, when your post-commit hook is not working, you get ZERO feedback for what is wrong. This is can be quite a time waster. But I finally found this nugget in the Subversion FAQ, that helps solve that problem:
subversion: Subversion FAQWhy aren’t my repository hooks working?They’re supposed to invoke external programs, but the invocations never seem to happen.
Before Subversion calls a hook script, it removes all variables
- including $PATH on Unix, and PATH on Windows -from the environment. Therefore, your script can only run another program if you spell out that program’s absolute name.Debugging tips:
If you’re using Linux or Unix, try running the script “by hand”, by following these steps:
1. Use “su”, “sudo”, or something similar, to become the user who normally would run the script. This might be httpd or www-data, for example, if you’re using Apache; it might be a user like svn if you’re running svnserve and a special Subversion user exists. This will make clear any permissions problems that the script might have. 2. Invoke the script with an empty environment by using the the “env” program. Here’s an example for the post-commit hook:
$ env – ./post-commit /var/lib/svn-repos 1234
Note the first argument to “env” is a dash; that’s what ensures the environment is empty. 3. Check your console for errors.
I hope that more people discover and use this very simple continuous integration plugin. It looks promising, but it needs a little more polish.