Add support for Rails 8.0 #2705
Open
+3,496
−444
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
So far, this is just a quick first-pass at opening up support, so we can make a little bit of progress with each additional change. As of right now, we're stuck here, as |
|
@nickcharlton looks like the |
|
With I've done a bunch of it, now I'm going to wait for CI to fail and see what else we need to do. |
|
I'm left fighting with Ruby, Rails versions and testing the combination along with Appraisal on CI. However, those are details in the scheme of getting this PR merged. If someone would like to test it out on their Rails 8.0 upgrade, feel free to go ahead — I'd be especially interested if there are any issues you see which might mean this takes longer than getting CI right. |
nickcharlton
force-pushed
the
nc-support-rails-8
branch
from
8b73057
to
0c13066
Compare
|
I'd started down the path of messing about with running Appraisals differently, because it was failing for various reasons. But remembered I'd actually started on this back in Feb as #2524. I've now merged that, so we're back in Ruby vs. Rails expected compatibility. It's time to drop some Ruby versions ahead of cutting the final version of v1, but unless this takes longer than today, I'd like to do that after this PR is merged. We'll see how it goes. |
|
Failing specs are only for Ruby 3.1 and won't be possible to fix I guess: To complete this PR we just might need to drop support for Ruby 3.1 in the next release? Can't wait for this PR to be merged |
|
I'd been trying a couple of different ideas for fixing CI — as it stands currently, I'm stuck on the following:
I'm going to give it a little more time, but not much before giving in and dropping incompatible Rubies (I'm stubborn, but even that has limits!). We're so close to releasing a significant breaking change anyway (in v1) holding off dropping versions over 3 years old seems a bit much. I was chatting with @louis-antonopoulos last night, who's working on a brand new Rails 8 application, which started off with Propshaft (as that's now the default). I'll open a new issue for this, but it's something we're going to have to do (but not necessarily in this PR). |
nickcharlton
force-pushed
the
nc-support-rails-8
branch
from
2bd6be3
to
9c4fe93
Compare
|
Quite a successful time this afternoon looking at running CI against the different versions of Rails we want. I ended up doing what Appraisal usually does in CI, but manually. This works to a point — but you can't run the schema on older versions of Rails. So if we take this approach, we need a solution to that. I'm on the fence at the moment about this. I do think the tradeoff of doing things this way is going to be helpful long-term, from seeing it fail the way it does, it's given me confidence it's actually running properly. But it's much more complex. |
nickcharlton
added a commit
that referenced
this pull request
Nov 21, 2024
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). Extracted from #2705.
nickcharlton
added a commit
that referenced
this pull request
Nov 21, 2024
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). Extracted from #2705.
nickcharlton
added a commit
that referenced
this pull request
Nov 21, 2024
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. Extracted from #2705.
nickcharlton
added a commit
that referenced
this pull request
Nov 21, 2024
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. Re-inline extracted Action
nickcharlton
force-pushed
the
nc-support-rails-8
branch
from
be030ce
to
3521870
Compare
nickcharlton
added a commit
that referenced
this pull request
Nov 21, 2024
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. Re-inline extracted Action
nickcharlton
added a commit
that referenced
this pull request
Nov 21, 2024
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.
nickcharlton
added a commit
that referenced
this pull request
Nov 21, 2024
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.
nickcharlton
force-pushed
the
nc-support-rails-8
branch
2 times, most recently
from
363e1ea
to
108308c
Compare
We needed to: * Bring over quite a few things from `rails app:update`, which hopefully should make future upgrades easier, * Fix a change to the `enum` `ActiveModel` signature, which changed between Rails 6.0 and 7.0, * Add a version check from 7.0 for `raise_on_missing_callback_actions` https://rubyonrails.org/2024/11/7/rails-8-no-paas-required Closes #2703
nickcharlton
force-pushed
the
nc-support-rails-8
branch
from
108308c
to
3277185
Compare
|
This is now ready to go. It took some re-thinking around CI, which I'm glad I did. I'm going to merge this in tomorrow morning so I can take another look at it, but it's working fine so far. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://rubyonrails.org/2024/11/7/rails-8-no-paas-required
Closes #2703