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

Rails7 test fixes #9231

Merged
merged 3 commits into from
Aug 6, 2024
Merged

Rails7 test fixes #9231

merged 3 commits into from
Aug 6, 2024

Conversation

jrafanie
Copy link
Member

@jrafanie jrafanie commented Jul 25, 2024

This is ready for review but depends on rails 7.

Note, this will only pass on rails 7 and is included in the core cross repo:

Depends:

@jrafanie jrafanie requested a review from a team as a code owner July 25, 2024 20:52
@miq-bot miq-bot removed the wip label Jul 25, 2024
@Fryguy Fryguy changed the title [WIP[ Rails7 test fixes [WIP] Rails7 test fixes Jul 26, 2024
@miq-bot miq-bot added the wip label Jul 26, 2024
:model_name => 'ManageIQ::Providers::CloudManager::Vm',
:model_name => 'VmOrTemplate',
Copy link
Member

@kbrock kbrock Aug 1, 2024

Choose a reason for hiding this comment

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

This value is from: @report_data_additional_options[:model]
via -- ApplicationHelper#model_to_report_data

Locally, this passed in x_active_tree = :instance_tree and got the correct model back in vm_common.rb

So this was passing for me.

Copy link
Member Author

Choose a reason for hiding this comment

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

So this was passing for me.

With rails 7 or 6.1?

FYI, ui-classic was failing with cross repo + rails 7 without this change.

Copy link
Member

Choose a reason for hiding this comment

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

ok, so this calls post 2 times: explorer and x_button.
In the explorer call, the db/model is ManageIQ::Providers::CloudManager::Vm
In the x_button the db/model is VmOrTemplate.

The explorer call sets the @report_data_additional_options.model to the current model, which is ManageIQ::Providers::CloudManager::Vm.
The x_button call will reuse the @report_data_additional_options.model value if it is present.

In 6.1, the x_button has the instance variable set, so the model is ManageIQ::Providers::CloudManager::Vm
In 7.0, actionpack-7.0.8.4/lib/action_controller/metal/testing.rb
has a method clear_instance_variables_between_requests. So @report_data_additional_options is not set and it sets the model to the current model, which is VmOrTemplate.

Conclusions

  1. The test may be setup incorrectly and the model should be the same for both calls. If this is a bug, it was probably always present in the test but did not rear it's head
  2. The test framework changed, this may be just a testing change.
  3. The expectation for instance variables in controllers may have changed and this may pose a problem in production.

Copy link
Member Author

Choose a reason for hiding this comment

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

I agree, this "could" have some impact on our existing UI code. I see get_view and get_db_view processing the show list options if this is not set. If we relied on subsequent requests to have these values persisted over requests, we will likely set rebuilding the options with possibly new/different values on subsequent requests. cc @GilbertCherrie @Fryguy. Great find @kbrock. I've been stumped looking at this one the past few several days off and on.

process_show_list_options(options, db) if @report_data_additional_options.nil?

if !fetch_data && @report_data_additional_options.nil?

Copy link
Member Author

Choose a reason for hiding this comment

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

Going forward, I think, this code is the right code but we'll have to merge this with the rails 7 branch as this will not pass on 6.1

Copy link
Member Author

Choose a reason for hiding this comment

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

Note, I'll summarize Keenan's findings and put it in the commit message as I will forget about the details in a few days or even hours.

Copy link
Member

Choose a reason for hiding this comment

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

@jrafanie Did you update the commit message? Just waiting for this before merge.

@@ -74,8 +74,8 @@

# http://localhost:3000/vm_infra/show/10000000000449
it 'can display VM details for vm with ems_custom_attributes and a null attribute name' do
vm_vmware.ems_custom_attributes.push(custom_attr1, custom_attr2)
expect(controller).to receive(:identify_record).and_return(vm_vmware)
vm_vmware.ems_custom_attributes = [custom_attr1, custom_attr2]
Copy link
Member

Choose a reason for hiding this comment

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

ems_custom_attributes is an association.
I think << may be a better approach

Copy link
Member

Choose a reason for hiding this comment

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

ok, so the issue is the custom attribute was created with a nil source.
If you create the attribute with :source => "VC", then this works great.

I do remember warnings that scopes will not properly pass across for collection.create. I am not sure if this is related.

Copy link
Member Author

Choose a reason for hiding this comment

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

WAT. That's crazy. So, why does it work with assignment?

Copy link
Member Author

Choose a reason for hiding this comment

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

Nice find. It's interesting that I still need the identify_record twice change below.

@@ -65,7 +65,7 @@

let(:custom_attr2) do
FactoryBot.create(
:custom_attribute,
:ems_custom_attribute,
Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for the great sleuthing @kbrock. I changed this to use the ems custom attribute factory which sets source to VC.

@@ -75,7 +75,7 @@
# http://localhost:3000/vm_infra/show/10000000000449
it 'can display VM details for vm with ems_custom_attributes and a null attribute name' do
vm_vmware.ems_custom_attributes.push(custom_attr1, custom_attr2)
expect(controller).to receive(:identify_record).and_return(vm_vmware)
expect(controller).to receive(:identify_record).twice.and_return(vm_vmware)
Copy link
Member Author

Choose a reason for hiding this comment

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

This is still needed.

Copy link
Member

Choose a reason for hiding this comment

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

agreed. I saw the same thing

It's was unclear at first why we don't hit this in rails 6.1
because on rails 7, we get VmOrTemplate as I would expect from this code:
https://github.com/ManageIQ/manageiq-ui-classic/blob/9761b105b3a0038f30c1b933c24bee99ea3daf0b/app/controllers/mixins/actions/vm_actions/ownership.rb#L71-L86

Keenan made the following findings:

This calls post 2 times: explorer and x_button.
In the explorer call, the db/model is ManageIQ::Providers::CloudManager::Vm
In the x_button the db/model is VmOrTemplate.

The explorer call sets the report_data_additional_options.model to the current model,
which is ManageIQ::Providers::CloudManager::Vm.

The x_button call will reuse the report_data_additional_options.model value if it is present.

In 6.1, the x_button has the instance variable set, so the model is ManageIQ::Providers::CloudManager::Vm
In 7.0, actionpack-7.0.8.4/lib/action_controller/metal/testing.rb has a method clear_instance_variables_between_requests.
So report_data_additional_options is not set and it sets the model to the current model, which is VmOrTemplate.
Without this, the source is set to nil and the ems custom attribute
may not be persisted correctly, causing a test failure.
@jrafanie jrafanie changed the title [WIP] Rails7 test fixes Rails7 test fixes Aug 2, 2024
@jrafanie jrafanie removed the wip label Aug 2, 2024
@miq-bot
Copy link
Member

miq-bot commented Aug 2, 2024

Checked commits jrafanie/manageiq-ui-classic@04ce526~...63dae15 with ruby 3.1.5, rubocop 1.56.3, haml-lint 0.51.0, and yamllint
2 files checked, 0 offenses detected
Everything looks fine. 🍰

@jrafanie jrafanie mentioned this pull request Aug 2, 2024
3 tasks
@Fryguy Fryguy closed this Aug 6, 2024
@Fryguy Fryguy reopened this Aug 6, 2024
@Fryguy Fryguy self-assigned this Aug 6, 2024
@Fryguy Fryguy merged commit 3e816bd into ManageIQ:master Aug 6, 2024
19 of 29 checks passed
@jrafanie jrafanie deleted the rails7_test_fixes branch August 6, 2024 17:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants