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.
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
Add Ruby 3.1 to CI and fix Rails 7 #2552
Changes from all commits
02ca68d
e820894
64d7e33
8a550cf
d23598e
c7bba85
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
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 patchingdefault_preview_path
.There was a problem hiding this comment.
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
requiresactive_record
.🎉
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
I can't imagine a failure if we've hardcoded
tr>td
. Because both theindex_spec
and theindex
have it like that being generated by Rails 6.But, if we keep this ternary, after Rails 7 upgrade,
index_spec
will start failing, becauseindex
hastd
insidetr
, while the spec would attempt to selectdiv>p
.There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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:
On Rails 6, it will generate a spec with lines like:
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 comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
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-codedtr>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.There was a problem hiding this comment.
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.
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 thatindex
should havetr>td
. But it doesn't, it still has<p><strong>
.There seem to be a massive misunderstanding on this.
There was a problem hiding this comment.
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:
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.