[x] Generate docker-compose.yml from rake for consistency
[x] Lean into Docker Compose for shell debugging
[x] Simplify calling Docker Compose for each ruby test
[x] Update Readme with development environment changes
[x] Define explicit Gemfiles for each minor version of ruby
[x] Get dependencies installing on Ruby 1.9.3 & Ruby 2.0.0 with Bundler 1
[x] Run Ruby 2.2 CI on Ubuntu 20.04 to make it pass
Why?
Went off down a path (lost to git rebase now) using docker run ruby:VERSION directly and it seemed to have less issues in terms of things failing, but I was having issues pinning gem versions. Turns out Bundler 1 doesn't do very well with "the latest version of this gem requires a newer ruby than you have", whereas Bundler 2 will figure that out quite happily. Progress is useful.
Go for the super explicit route and define a Gemfile for each version of ruby we're targeting. Also generate the docker-compose.yml from rake explicitly for all the supported versions, and define helper tasks for each of the rubies as well.
bundle exec rake test:all will still test them all, although we might need to resurrect the explicit threading you had (but we can call rake tasks from threads now) for prettier output. It currently prints a lot to the terminal and makes it unhappy - albeit succeeds in the end.
bundle exec rake docker:build[x.y.z] (or x.y) will build the image from our Dockerfile for the x.y.z or x.y version of ruby. This verifies the bundle install works for the gemspec on that version of ruby.
bundle exec rake docker:shell[x.y.z] opens a bash shell inside the docker image, with gems already installed and the local folder mounted at /app. This makes it easy for checking which versions of gems install. If we're having an issue where gems won't install, we can comment out the RUN … bundle install … line in the Dockerfile to have a debug environment for debugging bundle install.
bundle exec rake docker:test[x.y.z] runs the test suite against that version of ruby.
What?
docker-compose.ymlfrom rake for consistencyWhy?
Went off down a path (lost to git rebase now) using
docker run ruby:VERSIONdirectly and it seemed to have less issues in terms of things failing, but I was having issues pinning gem versions. Turns out Bundler 1 doesn't do very well with "the latest version of this gem requires a newer ruby than you have", whereas Bundler 2 will figure that out quite happily. Progress is useful.Go for the super explicit route and define a Gemfile for each version of ruby we're targeting. Also generate the
docker-compose.ymlfrom rake explicitly for all the supported versions, and define helper tasks for each of the rubies as well.bundle exec rake test:allwill still test them all, although we might need to resurrect the explicit threading you had (but we can call rake tasks from threads now) for prettier output. It currently prints a lot to the terminal and makes it unhappy - albeit succeeds in the end.bundle exec rake docker:build[x.y.z](or x.y) will build the image from our Dockerfile for the x.y.z or x.y version of ruby. This verifies thebundle installworks for the gemspec on that version of ruby.bundle exec rake docker:shell[x.y.z]opens a bash shell inside the docker image, with gems already installed and the local folder mounted at/app. This makes it easy for checking which versions of gems install. If we're having an issue where gems won't install, we can comment out theRUN … bundle install …line in the Dockerfile to have a debug environment for debugging bundle install.bundle exec rake docker:test[x.y.z]runs the test suite against that version of ruby.