Use Ruby 2.7 for development and CI

[guialbuk]

• User Ruby 2.7 for gem development
• Add Ruby 2.7 to CI matrix
• Update other Ruby versions
• Use bundler 1.x for Ruby 2.4 and 2.5 to keep Rails 4.2 compatibility

[mcmire]

Very nice! I just had one comment below.

[mcmire]

I wonder if it still useful to keep Bundler 1.x for development. Every so often, I find that tests fail on Rails 4.2, so in order to debug this I will re-run the tests locally using the rails_4_2 appraisal. I feel like Bundler 2.x doesn't work with Rails 4.2 (or it may be Ruby 2.4/2.5, as you put in your comment above, I'm not sure). So I feel like we might need to keep this? What do you think?

[guialbuk]

Hi @mcmire
Yeah, bundler 1.x is still needed for Rails 2.4 specs.
I removed the version restriction so the combination of Rails + Ruby can choose the most appropriate version.
Ruby 2.7 has no support for Bundler 1.x and Rails 4.2 requires bundler < 2 in its gemspec:

https://github.com/rails/rails/blob/c0cb0cbf976a3cf8ad1b0e2d0f813602a712e997/rails.gemspec#L30

The solution was to only use Bundler 1.x for Ruby 2.4 and 2.5, supported by Rails 4.2:

shoulda-matchers/.travis.yml

Lines 32 to 42 in 6757e32

	# Use Bundler 1.x for Ruby 2.4/2.5 and Rails 4.2
	- |
	if ruby --version | grep -E "2.(4|5)."
	then
	gem update --system '2.7.8' --no-document
	gem uninstall -v '>= 2' -i $(rvm gemdir)@global -ax bundler || true
	gem install bundler -v '< 2' --no-document
	else
	gem update --system --no-document
	gem update bundler --no-document
	fi

After these CI improvements, I feel like removing support for Ruby 2.4 and Rails 4.2. This would the codebase simpler and easier to contribute to. Some shims and ActiveRecord matches, especially belongs_to would benefit from that. But that's for a major release 😄

[mcmire]

Oh ok. So maybe this one's okay. What about the one in rails_4_2.gemfile, would you have to change that one then, at least?

[mcmire]

Hey, so I took another look at this and I still don't think that using Bundler 2 in development is going to work. The reason for this is that part of the routine for setting up development (or updating dependencies in general, in fact) is to run bundle exec appraisal install. (I mistakenly took it out of the bin/setup script recently but I'm working on putting it back in.) Unfortunately, this won't work when using Bundler 2 because the rails_4_2 appraisal won't allow it. So we have to be on Bundler 1.x for that to work. And I don't know about Ruby 2.7 not supporting Bundler 1.x, because I just tried pulling down your branch here and switching to Bundler 1.x under Ruby 2.7 and that seems to have worked. Try doing gem install bundler:1.17.3 then running bundle exec appraisal install and you'll see what I mean.

[guialbuk]

@mcmire Thanks 👍 I'll do more tests in TravisCI with Ruby 2.7 + Bundler 1.x.
I got some failures there but I'll dig deeper to find a way to use Bundler 1.x for all versions in CI

[mcmire]

@guialbuk I'm gonna try to see if I can figure this out today if that's alright with you!

[mcmire]

@guialbuk I think I got something to work. Wanna take another look at this? If you're good with it, I'd like to merge it in so that we can merge in #1314.

[mcmire]

I removed the version dependency on this because I was getting deadlock issues when using a version of RubyGems prior to 3.1.0.

[mcmire]

Caching was not working properly before. cache: bundler assumes that the install command is not being overridden — if that is the case then Bundler will use vendor/bundle as the installation path. However, since we are overriding install and we are not providing a --path to bundle install, Travis will install gems in a global location, which happens to be under /home/travis/.rvm/gems/ruby-<version>. Here I'm listing out all of the possible cache paths because it will change depending on which Ruby version the build is running under.

[guialbuk]

@mcmire Thanks a lot for looking into that. You ended up with a simple and elegant solution.
I'd approve the PR, but GitHub does not allow me as I created it 😄
Cheers!