ManageIQ
[WIP] Allow rails 7 gems in gemspec
Allow rails 7 gems in gemspec
Depends on:
- [x] https://github.com/ManageIQ/activerecord-id_regions/pull/33
- [x] New id_regions release (0.4.0)
- [ ] Extracted backward compatible changes: https://github.com/ManageIQ/manageiq-schema/pull/735
- [ ] Fix failures creating associations in migration specs due to ActiveRecord::AssociationTypeMismatch errors. Rails 7 only.
- [ ] Fix "secrets" related test failures with rails 7
This pull request has been automatically marked as stale because it has not been updated for at least 3 months.
If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).
rails 7.0 supports ruby 3.0 and 3.1 - so at least according to that, it should work
Oh, these are fun errors... looks like our migration_stub method is returning a cached constant and any associations you define in your migration "stub" fail under rails 7 because it's not a refresh association class.
Ok, all green, now to clean up the ENV stubbing migration 20180606155924_move_ansible_container_secrets_into_database
Ok, all green and cleaned up. The commits should be reviewable one by one.
Can you explain why we need the id changes? There are a gazillion of them. Are the relationships lost or something in the cached stubs?
Can you explain why we need the
idchanges? There are a gazillion of them. Are the relationships lost or something in the cached stubs?
Sure, I had it in each commit. Good idea. I just added it to the description:
Rails 7 changed the way migrations are run. The migration class constant is now removed and the file is reloaded between migrations.
This means tests should not use expect/allow on migration stub classes as the constant stubbed is not the same constant the migration is run against.
Additionally, comparisons of objects created before the migration with ones after will also not work. In that case, you can assert by id or other attributes instead of comparing objects.
Rails also checks association classes are correct and will also not match expectations. For example, instead of using host to create or query the host association, use host_id instead. This also works with has_manys such as miq_product_feature_ids.
See https://github.com/rails/rails/pull/42198
@jrafanie so you are converting from relations to ids so we can avoid defining relations all together? (e.g.: ext_management_system => ems to ems_id => ems.id)
Seems those are very non-rails specific and can be pulled out of here?
@jrafanie so you are converting from relations to ids so we can avoid defining relations all together? (e.g.:
ext_management_system => emstoems_id => ems.id)
Not specifically. I think that's beyond the scope here. The problem is that the association itself has logic to verify the class for the association. This verification doesn't work if you're trying to create an association with an object that is not the expected constant. This worked in 6.1 because the migration was loaded only once and the stub model constant remained. With rails 7, the migration stub model constants are removed and the migration is loaded again, so the classes aren't equivalent. What I'm doing here is avoiding the association method when I'm creating or comparing objects.
The migrations that define the associations can still use those association methods but I'm trying to avoid them in the tests for the issues found with rail 7.