Skip to content

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

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -30,6 +30,10 @@ jobs:
matrix:
include:
# Edge Rails (7.1) builds >= 2.7
- ruby: 3.1
allow_failure: true
env:
RAILS_VERSION: 'main'
- ruby: '3.0'
allow_failure: true
env:
Expand All @@ -41,19 +45,19 @@ jobs:

# Rails 7.0 builds >= 2.7
- ruby: 3.1
allow_failure: true
env:
RAILS_VERSION: '~> 7.0.0'
- ruby: '3.0'
allow_failure: true
env:
RAILS_VERSION: '~> 7.0.0'
- ruby: 2.7
allow_failure: true
env:
RAILS_VERSION: '~> 7.0.0'

# Rails 6.1 builds >= 2.5
- ruby: 3.1
env:
RAILS_VERSION: '~> 6.1.0'
- ruby: '3.0'
env:
RAILS_VERSION: '~> 6.1.0'
Expand Down
2 changes: 1 addition & 1 deletion Rakefile
Original file line number Diff line number Diff line change
Expand Up @@ -160,7 +160,7 @@ namespace :no_active_record do
sh "rm -f #{bindir}/rails"
sh "bundle exec rails new #{example_app_dir} --no-rc --skip-active-record --skip-javascript --skip-bootsnap " \
"--skip-sprockets --skip-git --skip-test-unit --skip-listen --skip-bundle --skip-spring " \
"--template=example_app_generator/generate_app.rb"
"--skip-action-text --template=example_app_generator/generate_app.rb"

in_example_app(app_dir: example_app_dir) do
sh "./ci_retry_bundle_install.sh 2>&1"
Expand Down
1 change: 1 addition & 0 deletions example_app_generator/generate_action_mailer_specs.rb
Original file line number Diff line number Diff line change
Expand Up @@ -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/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the key change to skip loading AR in no_ar_example_app, it's patching default_preview_path.

end
copy_file 'spec/verify_mailer_preview_path_spec.rb'
end
1 change: 1 addition & 0 deletions example_app_generator/generate_stuff.rb
Original file line number Diff line number Diff line change
Expand Up @@ -167,4 +167,5 @@ def using_source_path(path)
gsub_file 'spec/controllers/uploads_controller_spec.rb',
'skip("Add a hash of attributes valid for your model")',
'{}'

final_tasks
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
raise "ActiveRecord is defined but should not be!" if defined?(::ActiveRecord)

require 'active_model'

module InMemory
module Persistence
def all
Expand Down
7 changes: 7 additions & 0 deletions example_app_generator/spec/support/default_preview_path
Original file line number Diff line number Diff line change
Expand Up @@ -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"
Copy link
Member

Choose a reason for hiding this comment

The 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 no_ar_example_app.

action_mailbox requires active_record.

🎉

Copy link
Contributor Author

@petergoldstein petergoldstein Jan 18, 2022

Choose a reason for hiding this comment

The 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.
Expand All @@ -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

Expand Down
5 changes: 5 additions & 0 deletions example_app_generator/spec/verify_mailer_preview_path_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down Expand Up @@ -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
Copy link
Contributor Author

Choose a reason for hiding this comment

The 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'),
Expand Down
3 changes: 2 additions & 1 deletion lib/generators/rspec/scaffold/templates/index_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -18,8 +18,9 @@

it "renders a list of <%= ns_table_name %>" do
render
cell_selector = Rails::VERSION::STRING >= '7' ? 'div>p' : 'tr>td'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest moving this inside <% %> so it doesn't appear in the resulting spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine the flow as:

  1. generate a scaffold
  2. upgrade Rails from 6 to 7

I can't imagine a failure if we've hardcoded tr>td. Because both the index_spec and the index have it like that being generated by Rails 6.

But, if we keep this ternary, after Rails 7 upgrade, index_spec will start failing, because index has td inside tr, while the spec would attempt to select div>p.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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
Rails 7.x - div>p

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scaffold is generated dynamically as part of the spec run

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we've hardcoded

Sorry for being ambiguous.
By we I didn't mean me or you, I meant the template, lib/generators/rspec/scaffold/templates/index_spec.rb.
And by the product that will undergo hardcoding I meant the resulting index_spec.rb spec file on the real project's developer machine, not the template in this git repository.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

  • CI - for Rails 7 your approach will work for the generated index spec you reference (because the tr>td will be replaced in the generated spec. But the scaffold spec - spec/generators/rspec/scaffold/scaffold_generator_spec.rb - will fail, because it will have a hard-coded tr>td

  • Developer's Box - We have the same issue for the scaffold spec if we generate the app at one Rails version and switch to another. If a developer builds the smoke app under Rails 7, then the specs now fail. Why does Rails 6 have a preferential position over Rails 7? What happens if I generate the app on Rails 7 and move to Rails 6.

When a developer changes RAILS_VERSION then they should run bundle exec rake clobber generate:app generate:stuff. That solves the upgrade problem entirely.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

c68b568#diff-94efcbcbb995cd8f60c1956dbb889ec2af5999f3aef85e686278dd96b9a3be16R21

A competitive commit coincidentally implementing the approach I suggest.

Why does Rails 6 have a preferential position over Rails 7? What happens if I generate the app on Rails 7 and move to Rails 6.

There is no preferential approach. If you were on Rails 7, generated those specs with index with <p><strong>.
If you move to Rails 6 after, index_spec that will now start asserting that index should have tr>td. But it doesn't, it still has <p><strong>.

There seem to be a massive misunderstanding on this.

Copy link
Contributor Author

@petergoldstein petergoldstein Jan 12, 2022

Choose a reason for hiding this comment

The 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:

So either we duplicate the logic in the spec (which seems kind of pointless) or we put it in a single variable here.

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
7 changes: 5 additions & 2 deletions lib/rspec/rails/feature_check.rb
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The 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"?
I searched in https://rubyreferences.github.io/rubychanges/3.1.html and couldn't find anything related.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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"
end

def type_metatag(type)
Expand Down
2 changes: 1 addition & 1 deletion lib/rspec/rails/matchers/have_enqueued_mail.rb
Original file line number Diff line number Diff line change
Expand Up @@ -102,7 +102,7 @@ def process_arguments(job, given_mail_args)

def use_given_mail_args?(job)
return true if FeatureCheck.has_action_mailer_parameterized? && job[:job] <= ActionMailer::Parameterized::DeliveryJob
return false if FeatureCheck.ruby_3_1?
return false if FeatureCheck.rails_6_1_and_ruby_3_1?

!(FeatureCheck.has_action_mailer_unified_delivery? && job[:job] <= ActionMailer::MailDeliveryJob)
end
Expand Down
8 changes: 4 additions & 4 deletions spec/generators/rspec/scaffold/scaffold_generator_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -208,16 +208,16 @@
before { run_generator %w[posts upvotes:integer downvotes:integer] }
subject { file("spec/views/posts/index.html.erb_spec.rb") }
it { is_expected.to exist }
it { is_expected.to contain('assert_select "tr>td", text: 2.to_s, count: 2') }
it { is_expected.to contain('assert_select "tr>td", text: 3.to_s, count: 2') }
it { is_expected.to contain('assert_select cell_selector, text: Regexp.new(2.to_s), count: 2') }
it { is_expected.to contain('assert_select cell_selector, text: Regexp.new(3.to_s), count: 2') }
end

describe 'with multiple float attributes index' do
before { run_generator %w[posts upvotes:float downvotes:float] }
subject { file("spec/views/posts/index.html.erb_spec.rb") }
it { is_expected.to exist }
it { is_expected.to contain('assert_select "tr>td", text: 2.5.to_s, count: 2') }
it { is_expected.to contain('assert_select "tr>td", text: 3.5.to_s, count: 2') }
it { is_expected.to contain('assert_select cell_selector, text: Regexp.new(2.5.to_s), count: 2') }
it { is_expected.to contain('assert_select cell_selector, text: Regexp.new(3.5.to_s), count: 2') }
end

describe 'with reference attribute' do
Expand Down