Lock down bundler to pre-2.2.10 and fix ManageIQ::Environment.bundler_version

[agrare]

Bundler 2.2.10 has a bug causing bundle install to fail with gems being installed from one source that depend on gems from another. Until that is resolved we should lockdown bundler to max 2.2.9.

Also the ManageIQ::Environment.bundler_version regex isn't able to properly parse all gem requirements other than the first on. We can use the Bundler::Definition to parse the Gemfile "properly"

Alternative to: ManageIQ/manageiq-ui-classic#7634 (comment)

[agrare]

This would only return "~> 2.1"

[agrare]

>> version_requirements
=> [["~>", #<Gem::Version "2.1">], [">=", #<Gem::Version "2.1.4">], ["<", #<Gem::Version "2.2.10">]]

[agrare]

source $TRAVIS_BUILD_DIR/bin/ci/setup_ruby_env.sh
#!/bin/bash
./bin/ci/setup_ruby_environment.rb
Fetching bundler-2.2.9.gem
Successfully installed bundler-2.2.9
1 gem installed

[miq-bot]

Checked commit agrare@71e5a0b with ruby 2.6.3, rubocop 0.82.0, haml-lint 0.35.0, and yamllint
2 files checked, 0 offenses detected
Everything looks fine. 🍪

[agrare]

cc @Fryguy @NickLaMuro

[Fryguy]

LGTM, but does Bundler::Definition.build(gemfile, nil, {}).dependencies end up parsing the Gemfile? I'm concerned it will end up spitting out a 3rd and maybe even 4th copy of things like "override_gem"

[agrare]

Bundler::Definition.build(gemfile, nil, {}).dependencies does parse the Gemfile, that's a good question about override_gem I think it returns the "evaluated" gemfile so not one dependency per line-item but let me test that out.

[agrare]

Yeah so if I include e.g. override_gem "bundler", "=2.2.9" in bundler.d/*.rb then we only get the one dependency returned:

>> Bundler::Definition.build("Gemfile", nil, {}).dependencies.select { |dep| dep.name == "bundler" }
** override_gem("bundler", "=2.2.9") at /home/grare/adam/src/manageiq/manageiq/bundler.d/overrides.rb:9
=> [<Bundler::Dependency type=:runtime name="bundler" requirements="= 2.2.9">]

[NickLaMuro]

@agrare @Fryguy Cool, I didn't know about this script, and I do agree it is a better long term solution.

That said, it doesn't seem like the UI classic actually consumes this script like it does here in the base repo:

https://travis-ci.com/github/ManageIQ/manageiq-ui-classic/jobs/483230007#L254-L258

#### PULLED FROM THE TRAVIS OUTPUT

$ source bin/ci/before_install.sh
Gem 'bundler' is not installed
Fetching bundler-2.2.9.gem
Successfully installed bundler-2.2.9
1 gem installed

(bundler 2.2.9 here is only getting installed because that run is from the ManageIQ/manageiq-ui-classic#7634 build, and I am too lazy to find another)

So we might need to make some changes over in UI Classic regardless if we take this change or mine.

[agrare]

@NickLaMuro I believe the gem install bundler is done in bin/setup by ManageIQ::Environment.manageiq_plugin_setup(gem_root)

https://github.com/ManageIQ/manageiq-ui-classic/blob/master/bin/setup#L20

[agrare]

@miq-bot cross-repo-tests manageiq-ui-classic

[NickLaMuro]

@agrare Good point. I clearly was missing that bit when I was double checking, and I think I agree that what you have here should work.

That said, I think in this particular case, the cross-repo tests, while they appear to be working as expected, aren't a perfect replication since we are simulating a travis run, but not replicating it. So there is a chance it doesn't work quite the same.

That said, I think you are still good, so 👍 from me.