Add specs

[Fryguy]

Built on #3

Closes #1

[Fryguy]

@jrafanie Here's what I came up with

---

Still have to write specs for

• calling bundle check after the bundle update
• calling bundle exec after the bundle update

[jrafanie]

This looks really good... 👍

[Fryguy]

@jrafanie This is ready to go.

[Fryguy]

or @NickLaMuro :)

[NickLaMuro]

@Fryguy Would you be surprised by the fact that I have already started a review?

[Fryguy]

LOL nope 😂

[agrare]

Tested the following scenarios with ManageIQ/manageiq#18461 applied:

1. Picked up global ~/.bundler.d when run from manageiq repo on initial run of bundle update
2. Added override to manageiq/bundler.d then ran bundle update a second time, both global and local overrides present, bundle check successful
3. Switched to a plugin manageiq-providers-vmware that had spec/manageiq symlinked, bundle update picked up overrides and globals
4. Added local plugin override, bundle update picked up global, core, and plugin overrides, bundle check successful.

Any of the previous failures that we've seen are addressed from my point of view.

Just FYI

bundler --version
Bundler version 1.17.3
ruby --version
ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux-gnu]

👍 from me

[Fryguy]

I couldn't use BUNDLER_VERSION, because bundler itself uses that internally (it sets it after it reads the lockfile, or you can specify to override the lockfile), so instead I went with this more explicit env var name.

[NickLaMuro]

Well, this is a start. Still need to make my way through the specs themselves, but this is what I noticed while looking through the helper code.

[Fryguy]

@NickLaMuro Updated

[NickLaMuro]

Alright, I think I am fine with everything here.

Left a few minor nitpicks and commentary, but I wouldn't call any of it "merge blocking".

Looks good! 👍

[NickLaMuro]

Interestingly, this doesn't show up as light_yellow on Travis.

[Fryguy]

@NickLaMuro Updated. Thanks for the review!