Fix bundle override in ManageIQ::Environment

[Fryguy]

Commit 04d9a75 overrides Travis' built-in bundle install, which handles
bundle caching as well as parallel installs and retries, but did so
without any of those feature causing them to be lost in all of the
provider repos.

http://talk.manageiq.org/t/can-we-speed-up-small-repos-on-travis/2533

@bdunne Please review.
cc @durandom @cben

[miq-bot]

Checked commit Fryguy@d64fe19 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
1 file checked, 0 offenses detected
Everything looks fine. 🏆

[cben]

Thanks! 🎉
Unfortunately 💥 , I now see provider travises erroring on --path flag (which indeed I dont see in bundle update --help):
https://travis-ci.org/ManageIQ/manageiq-providers-kubernetes/jobs/254369323
https://travis-ci.org/ManageIQ/manageiq-providers-openshift/jobs/254733067
https://travis-ci.org/ManageIQ/manageiq-providers-openstack/jobs/254682962
https://travis-ci.org/ManageIQ/manageiq-providers-ansible_tower/jobs/254638729

Bundler version 1.15.2
...
$ bin/setup
== Cloning manageiq sample app ==
Cloning into 'spec/manageiq'...
Unknown switches '--path=vendor/bundle'
== Command ["bundle update --jobs=3 --retry=3 --path=${BUNDLE_PATH:-vendor/bundle}"] failed in /home/travis/build/ManageIQ/manageiq-providers-kubernetes ==

The command "bin/setup" failed and exited with 1 during .

(manageiq repo still works eg. https://travis-ci.org/ManageIQ/manageiq/jobs/254753082)

[durandom]

indeed only bundle install has the --path param

[Fryguy]

:( This is why we should just stick with what Travis has built in...fix coming soon

[cben]

I think it's important that ManageIQ::Environment PRs get tested on a plugin, in Travis before merging (local can't be good enough, we have ENV['CI'] conditionals, and Travis does its own magic)

• The simplest idea I can think of is including an "empty plugin" in core repo and testing it.
• More elegantly, could have a test that runs plugin generator and then tries its bin/setup :) Just need spec/manageiq symlink to use the ManageIQ::Environment code under test instead of checking out master.

Sounds fun, I'll make a PR for something like that.

Another lesson: consider adding some people in non-US timezone with core merge rights — can agree that they'll only use it to fix productivity-breaking things like red master, and/or will only do reverts...

(I also have a bigger plan to make travis read PR description and be able to specify "test this PR with those dependencies" as well as "also test it doesn't break those repos", but that needs more time)

[NickLaMuro]

Another lesson: consider adding some people in non-US timezone with core merge rights — can agree that they'll only use it to fix productivity-breaking things like red master, and/or will only do reverts...

Since I expect that this would come with some reservations from those dishing out those rights, possible alternative solution is that merging PRs like this should happen in the A.M. instead of near the end of the day. Otherwise you have people shipping and walking away for 12 hours and not being able to fix things and bottleneck others.

Possible a CI-Risk label, or something to that affect, should be added so that Mergers are aware that time should be allotted after a merge to monitor build statuses before stepping away.