-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Add Ruby 3.1 to CI and fix Rails 7 #2552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
02ca68d
e820894
64d7e33
8a550cf
d23598e
c7bba85
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -31,6 +31,7 @@ | |
if skip_active_record? | ||
comment_lines 'spec/support/default_preview_path', /active_record/ | ||
comment_lines 'spec/support/default_preview_path', /active_storage/ | ||
comment_lines 'spec/support/default_preview_path', /action_mailbox/ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the key change to skip loading AR in |
||
end | ||
copy_file 'spec/verify_mailer_preview_path_spec.rb' | ||
end |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,6 +26,11 @@ require_file_stub 'config/environment' do | |
require "action_controller/railtie" | ||
require "action_mailer/railtie" unless ENV['NO_ACTION_MAILER'] | ||
require "action_view/railtie" | ||
if Rails::VERSION::STRING >= '6' | ||
require "action_cable/engine" | ||
require "active_job/railtie" | ||
require "action_mailbox/engine" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's this line that's causing the "ActiveRecord is defined but should not be!" message in
🎉 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good detective work. I think the fix is slightly more complex than just removing that line, but we should be able to get everything but the ActionMailer dependency fixed pretty quickly. As noted elsewhere, the ActionMailer fix requires us to modify the mailer classes. Some work on my machine indicates that these changes may do it - petergoldstein#5 . I want to ensure they run green on CI before pushing to this branch. |
||
end | ||
|
||
# Require the gems listed in Gemfile, including any gems | ||
# you've limited to :test, :development, or :production. | ||
|
@@ -44,6 +49,8 @@ require_file_stub 'config/environment' do | |
if ENV['SHOW_PREVIEWS'] | ||
config.action_mailer.show_previews = (ENV['SHOW_PREVIEWS'] == 'true') | ||
end | ||
|
||
config.active_record.legacy_connection_handling = false if Rails::VERSION::STRING >= '7' | ||
end | ||
end | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -22,6 +22,9 @@ def capture_exec(*ops) | |
out = io.readlines | ||
.reject { |line| line =~ /warning: circular argument reference/ } | ||
.reject { |line| line =~ /Gem::Specification#rubyforge_project=/ } | ||
.reject { |line| line =~ /DEPRECATION WARNING/ } | ||
.reject { |line| line =~ /warning: previous/ } | ||
.reject { |line| line =~ /warning: already/ } | ||
.join | ||
.chomp | ||
CaptureExec.new(out, $?.exitstatus) | ||
|
@@ -108,6 +111,8 @@ def have_no_preview | |
end | ||
|
||
it 'handles action mailer not being available' do | ||
skip "Rails 7 forces eager loading on CI, loads app/mailers and fails" if Rails::VERSION::STRING.to_f >= 7.0 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @pirj Sure, this is a reasonable way to address the issue. |
||
|
||
expect( | ||
capture_exec( | ||
custom_env.merge('NO_ACTION_MAILER' => 'true'), | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,8 +18,9 @@ | |
|
||
it "renders a list of <%= ns_table_name %>" do | ||
render | ||
cell_selector = Rails::VERSION::STRING >= '7' ? 'div>p' : 'tr>td' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suggest moving this inside There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That won't help much. Something needs to appear in the resulting spec, and that something is going to be different for Rails 7.0 and for previous versions of Rails. So either we duplicate the logic in the spec (which seems kind of pointless) or we put it in a single variable here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I imagine the flow as:
I can't imagine a failure if we've hardcoded But, if we keep this ternary, after Rails 7 upgrade, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, that's exactly backwards. The scaffold is generated dynamically as part of the spec run. With the version of Rails that is currently active. So for you get: Rails 6.x - tr>td Hardcoding either one in the scaffold spec causes the scaffold spec to fail in at least one case. This is easy to confirm on the results on the current branch. With the current code the scaffold and the various index specs pass across all Ruby/Rails combos. Hardcoding will break it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
You think RSpec CI, I mean a real app developer's local machine. RSpec CI would be green both ways. Real app developer's local test run will fail with the way it is now. Please don't get me wrong, I suggest to: it "renders a list of <%= ns_table_name %>" do
render
<% for attribute in output_attributes -%>
assert_select <% Rails::VERSION::STRING >= '7' ? 'div>p' : 'tr>td' %>, text: Regexp.new(<%= value_for(attribute) %>.to_s), count: 2
<% end -%>
end
On Rails 6, it will generate a spec with lines like: assert_select 'tr>td', text: Regexp.new(3.to_s), count: 2 I think given the HTML table template Rails 6 used to generate, on developer's machine after update to Rails 7 this code will remain working. What makes this code problematic? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Sorry for being ambiguous. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So the suggested approach doesn't work. It breaks in CI and breaks on a developer's box.
When a developer changes RAILS_VERSION then they should run There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. c68b568#diff-94efcbcbb995cd8f60c1956dbb889ec2af5999f3aef85e686278dd96b9a3be16R21 A competitive commit coincidentally implementing the approach I suggest.
There is no preferential approach. If you were on Rails 7, generated those specs with There seem to be a massive misunderstanding on this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is no misunderstanding. You've implemented a version of the alternative that I described here. Specifically:
They've duplicated the logic from the index generator in the previously static scaffold spec. Note there is no mention of such a change in this comment. As I noted, the issue is we have dynamically generated things (index specs) and one statically generated thing (scaffold spec). Without the modification of the scaffold spec the specs would fail. To me it seems that duplicating the logic in two places (as is done in the referenced commit) is less ideal, but it's not a hill I want to die on. If there's a consensus that this approach is "better" I'm fine with that. As noted elsewhere, my goal is to get things working. Keep in mind that regardless of this spec's behavior, switching Rails versions without regenerating the smoke app would count as a bad idea. There's no guarantee that the generated app would i) run at all or ii) run consistently because there may be Rails version dependent changes. My earlier comment about blowing away and regenerating the Rails app when switching Rails versions still holds. |
||
<% for attribute in output_attributes -%> | ||
assert_select "tr>td", text: <%= value_for(attribute) %>.to_s, count: 2 | ||
assert_select cell_selector, text: Regexp.new(<%= value_for(attribute) %>.to_s), count: 2 | ||
<% end -%> | ||
end | ||
end |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -43,8 +43,11 @@ def has_action_mailbox? | |
defined?(::ActionMailbox) | ||
end | ||
|
||
def ruby_3_1? | ||
RUBY_VERSION >= "3.1" | ||
# TODO: add a self-explanatory method name. See https://github.com/rspec/rspec-rails/pull/2552#issuecomment-1009508693 for hints | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I couldn't. Can you please help me? Is there some explanation, like "the last hash argument is now treated as a positional argument instead of being auto-expanded into kwargs"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So I'm not sure there's a simple description other than "this is how it works for this combo". The Argument processing in the Rails codebase is pretty complex. There's an intersection of several changes happening at once, combined with an goal to keep support working from Ruby 2.5 to Ruby 3.1. That's a lot of moving parts, and I didn't try and dissect exactly what causes the change on input to rspec-rails. Then rspec-rails is post-processing the arguments with its own conditions, because of how it processes arguments to the matchers. So making that all line up is complicated, and I basically looked at the discrepancies and found the simplest resolution for the failing case. |
||
def rails_6_1_and_ruby_3_1? | ||
return false if RUBY_VERSION < "3.1" | ||
|
||
::Rails::VERSION::STRING >= "6.1" && ::Rails::VERSION::STRING < "7" | ||
pirj marked this conversation as resolved.
Show resolved
Hide resolved
|
||
end | ||
|
||
def type_metatag(type) | ||
|
Uh oh!
There was an error while loading. Please reload this page.