Add logstash plugin support to dynamic jenkins jobs
Merge pull request #232 from shrug/maint/qe-465

Add logstash plugin support to dynamic jenkins jobs
(maint) Always print root mock log on mock failure

Previously we would only print the root log if the build log was empty on a
mock failure. The root log often has valuable information in debugging mock
failures, so we should *always* print it out in a build failure.
Merge pull request #233 from haus/maint/master/things

(maint) Always print root mock log on mock failure
Break some monolithic gem functionality into methods

The spec is currently created on load of the gem.rake file, and the task
definition has a bunch of logic in it to. We're going to enable building
platform-specific gems, which means we need to be able to iterate over
platforms, creating multiple gems. To do this, we need to be able to call
methods more than once:) This commit moves the gem spec definition into a
method, and moves the logic for creating the gem into a method as well.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
(RE-54) Add a gem_platform_dependencies build object attribute

We're going to use this to allow users to specify dependencies that only apply
to certain platforms. The first key under the gem_platform_dependencies has to
be a value that corresponds to a value of RUBY_PLATFORM.

The subkeys are the same as the top-level gem dependency keys, e.g.:

gem_runtime_dependencies and gem_development_dependencies.

E.g., in a project_data.yaml file:

  gem_platform_dependencies:
    mingw32:
      gem_runtime_dependencies:
        win32process: '~> 0.7.4'

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
(RE-54) Build platform-specific gems

This commit adds additional functionality to the gem.rake file for creating
platform-specific gems with different dependencies. Using a new key in the
project_data.yaml file, we iterate over the platforms specified, building a gem
for each. A default gem, without a specified platform, is still created.
Platform-specific dependencies are *additive*, not replacing. That is, any
additional platform-specific dependencies will be added to the dependencies
listed under gem_runtime_dependencies and gem_devel_dependencies.
(RE-54) Enable shipping of multiple gems

So when we have platform-specific gems, we ship those too.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
(RE-54) Update readme for new platform-specific gem deps
Deprecate 'gem_devel_dependencies' in favor of 'gem_development_dependencies'

Though undocumented, we had specified gem_devel_dependencies as an allowed
parameter for @build, and it was supposed to correspond with
gem_development_dependencies in a gem spec. It was dumb to call it 'devel'
instead of 'development', which would have been a cleaner mapping. Here, we
deprecate this.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
(RE-54) Add sanity checking to platform-specific gems

This commit adds a bit of sanity checking to ensure that the platforms passed
as part of gem_platform_dependencies are actually usable by rubygems. The
object passed to Gem::Platform.new undergoes a series of parsing that includes
matching against various known platforms (which should handle all of our
use-cases). If a platform isn't recognized, the @os attribute of the returned
object is set to "unknown." Thus by checking for "unknown," we can ensure we
have a platform that rubygems will recognize.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Merge pull request #234 from MosesMendoza/RE-54/master/platform_gems

(RE-54) Enable expression of platform specific dependencies for gems
Make README.md explanation of templates more verbose

Explain that supplying templates overrides any defaults, rather than augments
them. This is to avoid confusion.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Merge pull request #235 from MosesMendoza/maint/master/update_readme_for_templates

Make README.md explanation of templates more verbose
(RE-477) Allow any vendor_gems task access to package:vendor_gems

For razor we will be invoking bundler from within rake from within jruby to
fetch the dependencies of the Gemfile. This will be accomplished by using an
auxiliary vendor_gems task called package:jruby_vendor_gems. In order for that
task to invoke the package:vendor_gems task, it must be defined even if the
pre_tar_task isn't equal to package:vendor_gems. This commit updates the task
to be defined if any pre_tar_task is defined.
Merge pull request #236 from haus/ticket/master/re_477_define_vendor_gems_task_for_all_pretar_tasks

(RE-477) Allow any vendor_gems task access to package:vendor_gems