With Rails 8, the minimum version of Ruby becomes 3.2. Unless we drop
support for prior Ruby versions (and also Rails versions), the way in
which we were approaching CI can't work. Maintaining support for older
Rails is not difficult because of Administrate itself, but how we
approach testing so it feels unreasonable to drop support (which if we
didn't test against it, we would effectively be doing) because it made
CI harder to do. And we _can_ make it work, so we will.
Previously, we ran the setup for the project as usual, and then ran
setup for the Appraisals. This served two functions:
1. Make Appraisal available in the bundle,
2. Setup the database for running tests against
However, in the CI matrix, we support multiple different versions of
Ruby (3.0 and up to 3.3). As we try and add Rails 8.0, this means we
can't run `bundle install` on those versions of Ruby below 3.2 as it's a
dependency constraint on Rails itself.
From experiments, we also can't:
1. Install Appraisal outside of the bundle, because it references gems
in a way that Bundler is there to solve,
2. Load newer `schema.rb` files in older versions of Rails. Rails 7
introduced versioned schemas, and future schema versions can't be run
with older versions of Rails.
Instead, what we _can_ do is run the project setup inside a container
configured to use the database in the CI environment, then manually do
what Appraisal is doing to avoid issues bundling.
This container will always use the current development version of Ruby
(3.2.2, at the time of this commit) taken from the `.ruby-version` file,
in which we run just enough to setup the database and ensure the later
tests can run against it.
It's unlikely that Administrate would do something which wasn't
supported at the database level, but not impossible. However these tests
would catch that (from experience: Rails falls back to a string on
unknown types, so it's even less likely to fail).
We also need to remove the Ruby version specification from the generated
Appraisal gemfiles, as otherwise these won't install. Whilst they seemed
to be valid outside of this way of running things, here, they are not.
We just use `sed` to remove it in place, as it can be discarded later
and removing it would cause problems with Heroku deployment of the demo
app.
Finally, we inline the previously extracted Action from #2524. The
intent was to reduce duplication, but the order of operations are now so
different it's not worth it and it would only be used in one place.
Extracted from #2705.