Skip to content
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

fix-finding-extension #2325

Closed
wants to merge 1 commit into from
Closed

fix-finding-extension #2325

wants to merge 1 commit into from

Conversation

@JonRowe
Copy link
Member

JonRowe commented May 5, 2020

👋 Thanks for contributing this! Seems like we need an integration test to check this as the current spec is obviously not enough to catch this, I believe 5.2 does string interpolation so this might be ok for all versions we support but I'm not sure.

@masarakki
Copy link
Author

masarakki commented May 5, 2020

I believe 5.2 does string interpolation

oh...
I think it may be ok with like this code

render_options[:variants] = [match[:variant], match[:variant].to_sym] if match[:variant]

@pirj
Copy link
Member

pirj commented May 5, 2020

We still soft-support 4.2, so intentionally breaking it would be irresponsible. Your code seems to be quite ok to support both. Can you please check if your fix works for your project?

May I ask you to add a note to remove stringified parts once we completely drop 4.2?

@masarakki
Copy link
Author

updated.

@masarakki
Copy link
Author

some error occurred in travis, but I can't detect what's wrong from error message.

@pirj
Copy link
Member

pirj commented May 6, 2020

That's weird, I can't reproduce locally, can you by running cucumber features/system_specs/system_specs.feature? Ruby 2.5.1 + Rails 6.0, all green.

@masarakki
Copy link
Author

masarakki commented May 6, 2020

all passes on my machine.
ruby 2.6.6 + rails 6.0.3

@benoittgt
Copy link
Member

The CI error happens in another build too. #2328 (comment)

I am gonna try to look at it, this afternoon.

@benoittgt
Copy link
Member

benoittgt commented May 8, 2020

Ok I don't know who is giving a status 9. I wrote a quick and dirty script

bin/rake clobber:app
bin/rake generate:app
bin/rake generate:stuff

mkdir -p tmp/example_app/spec/system/
tee -a tmp/example_app/spec/system/widget_system_spec.rb << END
require "rails_helper"
RSpec.describe "Widget management", :type => :system do
  before do
    driven_by(:selenium_chrome_headless)
  end
  it "enables me to create widgets" do
    visit "/widgets/new"
    fill_in "Name", :with => "My Widget"
    click_button "Create Widget"
    expect(page).to have_text("Widget was successfully created.")
  end
end
END

cd tmp/example_app/
bundle install
bundle exec rspec --backtrace spec/system/widget_system_spec.rb
echo $?

cd ../../

bin/cucumber features/system_specs/system_specs.feature

Capture d’écran 2020-05-08 à 20 56 17

The highlighted line show a status 0... then we a have a status 9... I don't get it. I am in favor of removing this status expectation. IMHO we should care only if the status is 0 or 1 but not something else.

@benoittgt
Copy link
Member

@mvz Do you have an idea for my last comment?
I dig into aruba's code to try to spot why we have a status 9 but didn't find an answer.

@JonRowe
Copy link
Member

JonRowe commented May 15, 2020

Feel free to cherry-pick 1f723f5 from #2332 into your branch which ignores the exit status 9 issue

@JonRowe
Copy link
Member

JonRowe commented May 15, 2020

You can also rebase this off master now

@mvz
Copy link
Contributor

mvz commented May 15, 2020

@mvz Do you have an idea for my last comment?
I dig into aruba's code to try to spot why we have a status 9 but didn't find an answer.

If aruba is doing its job properly this means rspec exits with status 9. I'm attempting to reproduce this locally to see if I can debug this.

https://github.com/rails/rails/blob/6-0-3/actionview/lib/action_view/template/resolver.rb#L349-L351

Resolver search files and resolve most matched file with **symbolized** string,
so `_default_render_options` must return symbolized values.
@pirj
Copy link
Member

pirj commented May 18, 2020

Rebased on master.

@pirj
Copy link
Member

pirj commented May 18, 2020

@masarakki Sorry for the trouble with CI.
Are you up to add an integration test somewhere in features/view_specs/view_spec.feature that fails without your change?

render_options[:handlers] = [match[:handler]] if match[:handler]

# remove stringified parts when dropping rails-4.x support
render_options[:handlers] = [match[:handler], match[:handler].to_sym] if match[:handler]
Copy link
Member

Choose a reason for hiding this comment

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

We don't want to match both, we just want to match the right type for each rails version.

@@ -148,19 +148,19 @@ def _default_file_to_render; end # Stub method
it "converts the filename components into render options" do
allow(view_spec).to receive(:_default_file_to_render) { "widgets/new.en.html.erb" }
view_spec.render
expect(view_spec.received.first).to eq([{template: "widgets/new", locales: ['en'], formats: [:html], handlers: ['erb']}, {}, nil])
expect(view_spec.received.first).to eq([{template: "widgets/new", locales: ['en', :en], formats: [:html], handlers: ['erb', :erb]}, {}, nil])
Copy link
Member

Choose a reason for hiding this comment

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

The problem with these specs are they are making exact expectations on value we know we're sending, we need an integration test for this that shows its a problem that they are not symbols.

@pirj
Copy link
Member

pirj commented May 24, 2020

@masarakki Sorry for pushing. Will you have a moment to wrap this up?

@masarakki
Copy link
Author

masarakki commented Jul 5, 2020

It is easy to match only right type for rails version, but it is very hard to test it.
We should test which file rendered, not what the parameters are.

@JonRowe JonRowe changed the base branch from master to main August 2, 2020 02:13
@JonRowe JonRowe mentioned this pull request Jan 18, 2022
21 tasks
@leboshi
Copy link

leboshi commented Mar 17, 2022

FYI, this PR is moot as of 3ccd1f, 1/20/2022.

@pirj
Copy link
Member

pirj commented Mar 18, 2022

Should we close this, @masarakki ? Does it resolve your case?

@masarakki masarakki closed this Mar 20, 2022
@masarakki masarakki deleted the fix-finding-extension branch March 20, 2022 06:41
@masarakki
Copy link
Author

this problem fixed by #2521 .
thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants