Archive for April 2009
We encountered an interesting problem today. while getting automated acceptance tests running in TeamCity.
Why Rake? :
- Rakefiles (rake‘s version of Makefiles) are completely defined in standard Ruby syntax. No XML files to edit. No quirky Makefile syntax to worry about (is that a tab or a space?)
- Users can specify tasks with prerequisites.
- Rake supports rule patterns to synthesize implicit tasks.
- Flexible FileLists that act like arrays but know about manipulating file names and paths.
- A library of prepackaged tasks to make building rakefiles easier.
What are we using it for?
Our rake file consists of a single task instructing the ruby interpreter to run cucumber with a set of fixtures — simple.
What were the symptoms?
We found that our build would “fail” as soon as we issued the shell command. The rest of the process works as expected — cucumber runs all the test and we get the results logged.
Finally we tracked this down to unexpected behaviour in the TeamCity rake runner.
What was the cause?
The TeamCity rake runner is designed to capture all output from rake, and redirect it to the appropriate TeamCity log.
# Send the message to the default rake output (which is $stderr). def rake_output_message(message) $stderr.puts(message) end
The TeamCity rake runner has overridden this in an attempt to capture these messages. For some reason this implementation sends an error message to TeamCity.
This means that all shell commands fail when running under the TeamCity rake runner.
Why does rake write to $stderr by default?
Don’t know. And the method name is not very evocative: rake_output_message.
Perhaps it’s intended to be overridden.
EDIT, 07-05-2009: All of these issues have been resolved by upgrading to latest version — even the teamcity-deletes-rake-file wrongness.