feat: Add Rails 7.1 - 8 support #141
Conversation
- remove it from the ci matrix - bump required_ruby_version in the gemspec - remove call to `ruby` in Gemfile, regen appraisals - bump TargetRubyVersion in rubocop.yml - and rubocop -a, since all of these are HashSyntax changes
- We also rm secrets.yml from the dummy app to deal with a deprecation warning - And updated the dummy application.rb to `config.load_defaults` for Rails 7 and 7.1 (whilst dropping previous versions)
and update `her` code to address a deprecation warning; https://github.com/rails/rails/blob/v7.2.2.1/activesupport/lib/active_support/proxy_object.rb
and update the dummy app config, as well as the ci matrix
.github/workflows/ci.yml
Outdated
| @@ -11,10 +11,12 @@ jobs: | |||
| runs-on: ubuntu-latest | |||
| strategy: | |||
| matrix: | |||
| ruby: [3.0, 3.1, 3.2] | |||
| ruby: ["3.2"] | |||
There was a problem hiding this comment.
3.1 is technically still supported for a couple months -- since this is an open source client I might be inclined to increment required_ruby_version more slowly and keep support for 3.1 unless it's too costly for us.
There was a problem hiding this comment.
We can always exclude combinations in the matrix if 3.1 isn't compatible with newest Rails.
Rails 8 requires 3.2
argvniyx-enroute
force-pushed
the
argv/rails-7-1-plus-support
branch
from
405628b to
d338dd7
Compare
`railties`'s constraint on zeitwerk is '~> 2.6' (or 2.5 for older Rails), which means that bundle updating can put us on 2.7, which requires Ruby 3.2. This will break CI tests for Ruby 3.1. When we drop support for 3.1, we can unpin this dep (i.e. not even list it at all, as before).
test_track_rails_client.gemspec
Outdated
| s.add_dependency 'request_store', '~> 1.3' | ||
| s.add_dependency 'sprockets-rails' | ||
| s.add_dependency 'zeitwerk', '< 2.7' |
There was a problem hiding this comment.
We get (AFAICT) zeitwerk because of railties, for which the constraint is ~> 2.6 (https://rubygems.org/gems/railties/versions/8.0.1; or ~> 2.5 for older Rails). The problem is that that means that bundle update can bump us to 2.7, which requires Ruby 3.2, effectively breaking 3.1 tests.
There was a problem hiding this comment.
I don't think we need to constrain the Zeitwerk version at runtime. We should move this to development dependencies.
spec/dummy/config/application.rb
Outdated
| config.load_defaults 7.0 if rails_version_between?('7.0', '7.1') | ||
| config.load_defaults 7.1 if rails_version_between?('7.1', '7.2') | ||
| config.load_defaults 7.2 if rails_version_between?('7.2', '8.0') | ||
| config.load_defaults 8.0 if rails_version_between?('8.0', '8.1') |
There was a problem hiding this comment.
| config.load_defaults 7.0 if rails_version_between?('7.0', '7.1') | |
| config.load_defaults 7.1 if rails_version_between?('7.1', '7.2') | |
| config.load_defaults 7.2 if rails_version_between?('7.2', '8.0') | |
| config.load_defaults 8.0 if rails_version_between?('8.0', '8.1') | |
| config.load_defaults Rails::VERSION::STRING.to_f |
We can also delete rails_version_between?
instead of `rails_version_between`
Summary
/task https://app.asana.com/0/1205835826533561/1209206146090339/f
This:
betterlint(and inbundle updateing, bumpsrubocop)rubocop -a's a bunch of HashSyntax lintsI realize that there's a lot going on here; mostly dealt with it as I went along, so I'm happy to break this into multiple PRs.
Other Information
The rubocop changes come from bumping the TargetRubyVersion, but I realized we do not do
NewCops: enable. Lints stemming from that were less straightforward than the HashSyntax lints, so I decided to hold off for now./domain @Betterment/test_track_core
/platform @Betterment/test_track_core