Fix explosion in RSpec 2 `example_failed` method

This is a long-standing bug in the RSpec 2 formatter, but we've never
noticed because the only project we've ever tested Buffet with using
RSpec 2 is Buffet itself, and that had no failing specs.

Related story:
  http://www.pivotaltracker.com/story/show/27318939 (fixed)
  ("Fix explosion in RSpec 2 `example_failed` method")

Change-Id: Iad9d898e9e21a438f0aef4d381882d55132547b2
Reviewed-on: https://gerrit.causes.com/4681
Tested-by: Greg Hurrell <greg@causes.com>
Reviewed-by: Steve Dee <steven.dee@causes.com>
Fix references to non-existent local `slave_name` variable

Related story:
  http://www.pivotaltracker.com/story/show/27318939 (fixed)
  ("Fix explosion in RSpec 2 `example_failed` method")

Change-Id: I719feb46a1022da636006a35994187707804d133
Reviewed-on: https://gerrit.causes.com/4685
Reviewed-by: Steve Dee <steven.dee@causes.com>
Tested-by: Greg Hurrell <greg@causes.com>
Use correct gem name in the README

Change-Id: Ide5a09a47d51b92d8109e3d8dc75d14814930d68
Reviewed-on: https://gerrit.causes.com/4688
Reviewed-by: Greg Hurrell <greg@causes.com>
Tested-by: Greg Hurrell <greg@causes.com>
Bump version number for 1.1.1 release

We want to cut a new release including the fixes for working with RSpec
2.

Change-Id: I05c04b2219c6a700d22ea1f5fa1327fdab3a0c17
Reviewed-on: https://gerrit.causes.com/4687
Tested-by: Greg Hurrell <greg@causes.com>
Reviewed-by: Greg Hurrell <greg@causes.com>
Fix pending specs under rspec2 runner

The method signature for example_pending has changed between rspec1 and
rspec2. The rspec2 formatter wasn't aware of this change, causing specs
marked as pending to appear to be failing.

Change-Id: Ib591e46b14d86a4fa8a5bd35dbc766675df2ae09
Reviewed-on: https://gerrit.causes.com/4927
Reviewed-by: Noah Silas <noah@causes.com>
Tested-by: Noah Silas <noah@causes.com>
Bump version number for 1.1.2 release

Change-Id: I9f4b4aaf6937f28f53dc2f2a25b7268cd3b7158c
Reviewed-on: https://gerrit.causes.com/4928
Reviewed-by: Noah Silas <noah@causes.com>
Tested-by: Noah Silas <noah@causes.com>
Allow the worker command to be customized

This was hard-coded to .buffet/buffet-worker; making it customizable
will allow for more advanced usage like setting up RVM.

Change-Id: I9a2a174eb1f607ff5e0050d8d2b52a1174dd0952
Reviewed-on: https://gerrit.causes.com/6386
Reviewed-by: Greg Hurrell <greg@causes.com>
Tested-by: Lann Martin <lann@causes.com>
Make `Settings#load_file` a private method

This looks like it should be an internal implementation detail, and
apart from one (ab)use it wasn't being used outside the class, so this
commit makes it a private method.

The one external caller was instead taught to use a `.settings_file=`
accessor method.

Change-Id: I76ea3440e534d5ef3ecdb1a632b5becb9cd3037c
Reviewed-on: https://gerrit.causes.com/9275
Tested-by: Greg Hurrell <greg@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Teach Buffet to write per-build log files

All Buffet runs share a single log file and it quickly becomes
unmanageably large. Furthermore, because multiple Buffet runs can be
occurring at the same time, the log output can become interleaved in
confusing ways. Teach Buffet to write a separate log file for each
build.

Buffet now understands a `-l`/`--log` option which can be used to pass
in a log file name at runtime. In a Jenkins set-up you would typically
make this some combination of project name and build number.

If the `-l`/`--log` option isn't passed, the settings file ("buffet.yml"
by default) will be consulted, and the final fallback will be the
default of "buffet.log".

Incidentally, did some minor tweaking along the way to enforce
consistent naming (eg. "log_dir" vs "logdir").

Related story:
  http://www.pivotaltracker.com/story/show/32200237
  ("Teach Buffet to write per-build log files")

Change-Id: Idf831a17a5c0136316b4fd429d41687c2b2481ad
Reviewed-on: https://gerrit.causes.com/9276
Tested-by: Greg Hurrell <greg@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Bump version to 1.2

Change-Id: I60753751d589272a0b8cc2e8b0fac8b0d5a90b0b
Reviewed-on: https://gerrit.causes.com/9277
Tested-by: Greg Hurrell <greg@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Fix Ruby 1.9 compatibility issue in options passing

Wrap "spec" in an array so that Ruby 1.9 doesn't freak out when we call
`#each` on it.

Related story:
  http://www.pivotaltracker.com/story/show/32230263 (fixed)
  ("Fix Ruby 1.9 compatibility issue in options passing")

Change-Id: I90e26c7469e9042913feffdeb897375a9cc30534
Reviewed-on: https://gerrit.causes.com/9315
Reviewed-by: Greg Hurrell <greg@causes.com>
Tested-by: Greg Hurrell <greg@causes.com>
Use Ruby 1.9 compatible require format in worker script

Use an absolute path when requiring the RSpec formatter, as this will
work on both Ruby 1.8.7 and Ruby 1.9.x.

Related story:
  http://www.pivotaltracker.com/story/show/32230861 (fixed)
  ("Use Ruby 1.9 compatible require format")

Change-Id: I08920900dc74c7612865ffa00a3c335f59de03e8
Reviewed-on: https://gerrit.causes.com/9316
Reviewed-by: Aiden Scandella <aiden@causes.com>
Reviewed-by: Richard Zschech <richard.zschech@causes.com>
Tested-by: Greg Hurrell <greg@causes.com>
Bump version number for 1.2.1 release

Change-Id: I28929638c3f46374eab22f175d11cab3f418c34e
Reviewed-on: https://gerrit.causes.com/9317
Reviewed-by: Aiden Scandella <aiden@causes.com>
Tested-by: Greg Hurrell <greg@causes.com>
Return information about example groups on failure

Example#execution_result[:exception] only has information about the
example that failed, which does not include the example group for
shared examples. This appends the calling location to the failure
message for shared examples.

Reference code: https://github.com/rspec/rspec-core/blob/v2.8.0/
                  lib/rspec/core/formatters/base_text_formatter.rb#L178

Change-Id: I8d3ae6583c1b66ffa3a5e1021e47ce371d69d431
Reviewed-on: https://gerrit.causes.com/9699
Reviewed-by: Elliot Block <elliot.block@causes.com>
Tested-by: Lann Martin <lann@causes.com>
Bump version number for 1.2.2 release

Change-Id: I67b9e5df02978f02d9815762c28a127cdab30f34
Reviewed-on: https://gerrit.causes.com/9922
Reviewed-by: Lann Martin <lann@causes.com>
Tested-by: Lann Martin <lann@causes.com>
Append failed shared example info to location, not message

Shared example caller info was being displayed at the end of failure
output, which can be confusing when there are multiple failures.

Append the info to the location string instead, which seems more
sensible anyway.

Change-Id: I93dd5b7d8fffa73b5d99d2c3df66db415954331c
Reviewed-on: https://gerrit.causes.com/11961
Tested-by: Lann Martin <lann@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Fix indentation of Master#run_slave

Noticed this while working on another commit.

Related Story:
  http://www.pivotaltracker.com/story/show/40166629
  ("Buffet should gracefully continue when a node is down")

Change-Id: Ia3aa4fb0d3cddcfbb185a0da3a66dd3875053a95
Reviewed-on: https://gerrit.causes.com/16101
Reviewed-by: Lann Martin <lann@causes.com>
Tested-by: Shane da Silva <shane@causes.com>
Raise CommandError when shell command fails

In the effort to make Buffet resilient to hosts going down, it was first
identified that we swallow all failures in external shell commands. This
becomes problematic if we want to bubble up the failure to the Master to
properly handle.

The solution was to add a `CommandError` exception that would wrap the
result of a shell command in the event a non-zero exit status was
returned.

Related Story:
  http://www.pivotaltracker.com/story/show/40166629
  ("Buffet should gracefully continue when a node is down")

Change-Id: I22f433d352c524637860f5a4c8a19285fa9cae67
Reviewed-on: https://gerrit.causes.com/16102
Reviewed-by: Lann Martin <lann@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Tested-by: Shane da Silva <shane@causes.com>
Add 'allowed_prepare_slave_failures' setting

This setting specifies how many slaves can fail in the prepare_slave
step without stopping the entire spec run, making it more resilient as
we increase the number of possible points of failure by adding more
machines.

At a high level, this commit:

  * Changes the messaging structure of the Master and its threads to use
    a ConditionVariable to signal/wait for updates from threads

  * Adds support for respecting the `allowed_prepare_slave_failures`
    setting to continue the test run unless the threshold has been
    exceeded

  * Updates the output from the Runner to display slave preparation
    failures

The bulk of this commit is in the redesigning of the Master to use a
condition variable as a signal mechanism. Previously, the Master spawned
a thread for each slave and then joined each of those threads so the
main thread would halt until all slaves had finished.

The problem with this approach is that if a failure occurs during
preparation, we don't find out about it until after we have joined the
failing thread. Thus a situation could arise where with 10 threads the
first 8 we spawn have no problems and run to completion, but the last 2
threads immediately fail due to being unable to connect to a host. In
this case, even though we could have stopped execution of the entire run
due to the 2 failures, we had to wait for the first 8 threads to finish.

The solution is to use signals so that the Master blocks on a single
condition variable, and can be signaled by any of the threads at any
time.

Change-Id: Id1852b4b7910c59a4262990447858c6a532ec703
Reviewed-on: https://gerrit.causes.com/16103
Reviewed-by: Lann Martin <lann@causes.com>
Reviewed-by: Greg Hurrell <greg@causes.com>
Tested-by: Shane da Silva <shane@causes.com>
Bump version number to 1.2.3

Change-Id: I7e80a947780b1270d9592f812acce6e7067c3354
Reviewed-on: https://gerrit.causes.com/16174
Reviewed-by: Aiden Scandella <aiden@causes.com>
Tested-by: Shane da Silva <shane@causes.com>