Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

We're probably going to see some more failures with this change, but that's a good thing. If we have a bad kitchen change or a bad cookbook change we'll know now earlier. Less impact == better.

Signed-off-by: Tim Smith <tsmith@chef.io>

* Remove call to update_omnibus_overrides

The rake tasks `update_omnibus_overrides` was removed in dafd5139338aed684410e311b9be906b346db678.

* Update acceptance/Gemfile.lock to match Gemfile.lock for mixlib-shellout

This should fix acceptance where we're seeing both mixlib-shellout 2.3.1 and 2.3.2.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

this is also necessary for bundler-1.14.x

i'm still not entirely clear why we ever needed all the fussy software gem
configs or what the build-chef / build-chef-gem infrastructure ever
did for us.  it seems to have been mostly micro-optimization around
building the software gems before bundle installing the project in order
to take advantage of git caching.  i aggressively don't care about that,
this is quite fast enough.  we can install nokogiri and libgecode early
and that should take care of 98% of the build optimization issue.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

See the PR comments for more philosophical background.

This simplifies the external tests.  The major feature here is that
halite, poise, chefspec, etc are removed from the Gemfile.lock and
the transitive Gemfile splicing is gone from the external tests.

We're back to simply tracking master on external projects and bundle
installing without locks and going red if the break.  Those external
projects should all similarly track master of chef/chef to reduce
the possibility that they break us here.

This also bumps bundler to 1.14.x and unblocks us there.

It continues to simplify our use of bundler to be more mainstream and
less impenetrable.

There was some crazy shit that I found where I had to remove env vars
like BUNDLE_ENABLE_TRAMPOLINE and the BUNDLE_IGNORE_CONFIG and
BUNDLE_FROZEN env vars in appveyor along with the .bundle/config frozen
setting were necessary to unbreak appveyor.  We seem to have gotten
very far afield of standard bundler usage and it was breaking in strange
to debug ways.

Oddly enough this exposed weird errors in the
chef-config/spec/units/fips_spec.rb tests where we need to require the
"win32/registry" file there now even though I can't figure out why that
broke or how it was working previously.

Also, adding x64-mingw32 to x86-mingw32 was necessary to test in
appveyor on 64-bit windows (I tried universal-mingw32 and that failed)
which seems obvious and is another case that I don't understand how it
was working in bundler 1.12.x

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

applies the same kinds of fixes that i applied to rake dependencies:*
and mostly reverts to mainline usage of bundler.  abandons all the
trampolining, and uses the platforms that are already locked in
the Gemfile.lock and unwinds the multi-platform stuff that bundler
does natively now.

removes the BundleUtil module entirely since it is no longer used.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

this eliminates all the "run gem pristine" warning spam
and i believe uses "bundle lock" correctly.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

This reverts commit 6628f708acdefe2fc6bff85a1edade89f0b4d8ee.

oops.

this eliminates all the "run gem pristine" warning spam
and i believe uses "bundle lock" correctly.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>