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

Fixes #37825 - Upgrade Rails to 7.0 #10299

Open
wants to merge 9 commits into
base: develop
Choose a base branch
from

Conversation

ofedoren
Copy link
Member

Based on #10131, but with additional commit needed for Rails upgrade.

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

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

In #9328 I also updated spring. Is that not needed? I recall running into it, but that could have been a Ruby thing or I was just looking at changelogs.

app/models/concerns/hostext/token.rb Outdated Show resolved Hide resolved
Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

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

Have you tried if moving the settings into initializers works with Rails 6.1?

Comment on lines 94 to +95
class ::FakePlugin; end
class ::FakePlugin::FakeModel; end
class ::FakePlugin::FakeModel < ApplicationRecord; end
Copy link
Member

Choose a reason for hiding this comment

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

Should this even be

module FakePlugin
  class FakeModel < ApplicationRecord
  end
end

@ofedoren ofedoren force-pushed the rails-7.0 branch 2 times, most recently from b2971c8 to c93acc6 Compare September 16, 2024 14:10
@ofedoren ofedoren changed the title Rails 7.0 Fixes #37825 - Upgrade Rails to 7.0 Sep 16, 2024
@ofedoren ofedoren marked this pull request as ready for review September 16, 2024 15:02
@ofedoren ofedoren requested a review from a team as a code owner September 16, 2024 15:02
@ekohl ekohl mentioned this pull request Sep 17, 2024
@ofedoren
Copy link
Member Author

There left only one test failure, I'm looking into it, for now I've got no clue :/

Apart from that, it's ready unless we want to be more correct and apply/incorporate these changes: https://railsdiff.org/6.1.7.8/7.0.8.4

@ofedoren
Copy link
Member Author

Now it fails due to ldap_fluff, since it's locked on active_support < 7 (https://github.com/theforeman/ldap_fluff/blob/master/ldap_fluff.gemspec#L21). Weird that it didn't fail before...

Also, @ekohl and @adamruzicka or maybe @ShimShtein, since you have more experience with the codebase and Rails, could you please help me get why the test fails? I'll be out for the next week (30.09 - 06.10), so I hope we won't waste that week.

Regarding the test: I think it's due to code reloading happening somewhere in the test:units suit since running each of test/models, test/helpers and test/unit separately works, it works even if run rails test test/models test/helpers test/unit, which is the same what rake test:units does. Setting test_order = :sorted doesn't help. Also, I've noticed that for some reason it can pass twice in a row, but another run would fail.

app/models/nic/base.rb Outdated Show resolved Hide resolved
@ofedoren
Copy link
Member Author

ofedoren commented Oct 9, 2024

Finally, it's green and with minimal changes needed. Ready for full review.

@ekohl
Copy link
Member

ekohl commented Oct 22, 2024

As noted in a meeting, the failure may be due to nulldb:

- 'assets:precompile RAILS_ENV=production DATABASE_URL=nulldb://nohost'

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

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

@ofedoren I see you now disable spring for integration tests and enable bootsnap for tests. Do you consider the issue resolved with that?

Additionally, is there a way we could use spring for integration tests? Possibly by explicitly stopping the server `

@@ -10,7 +10,8 @@
# test suite. You never need to work with it otherwise. Remember that
# your test database is "scratch space" for the test suite and is wiped
# and recreated between test runs. Don't rely on the data there!
config.cache_classes = true
# Disable reloading for integration tests
config.cache_classes = ARGV.grep(/test\/integration/).any?
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be the other way around? Only enable it when it's none??

Also, https://github.com/rails/spring?tab=readme-ov-file#enable-reloading notes it needs to be false for spring to work.

Another note: https://github.com/rails/spring?tab=readme-ov-file#temporarily-disabling-spring says:

If you're using Spring binstubs, but temporarily don't want commands to run through Spring, set the DISABLE_SPRING environment variable.

@ofedoren
Copy link
Member Author

ofedoren commented Nov 1, 2024

@ofedoren I see you now disable spring for integration tests and enable bootsnap for tests. Do you consider the issue resolved with that?

I'd say so, yes. Mostly because of spring being disabled for integrations. I don't think bootsnap did anything though. I just enabled that since it should be quite safe and maybe help us in the future.

Additionally, is there a way we could use spring for integration tests? Possibly by explicitly stopping the server

How that will help except for running integration tests on local dev setup? I mean, the whole point of spring for tests is to reduce time between individual calls/runs after the first one. In CI it doesn't matter, since there is only one (the first) run. For local dev runs it makes life easier, thus I've tried to leave the cache_classes set to false for other test types (e.g. units). Integration test suite takes a long time anyway, it easier to use CI for that then wait for local results. Moreover, we didn't have reloading for tests ever before.

Honestly, I'm quite surprised that reloading for units/functionals seems to work at all. I'd say reloading was (and still is) mostly unsupported within Foreman and even if it worked, it kidna shouldn't (I might be wrong though, just an impression).

Also, https://github.com/rails/spring?tab=readme-ov-file#enable-reloading notes it needs to be false for spring to work.

Yes, cache_classes set to false is the same as enable_reloading set to true starting Rails 7.1. Spring with Rails 7.0 forces reloading to be set to true for test environment as well, which is per my opinion weird: dev env with reloading makes sense to make and see the changes faster, but the test environment should rather mimic prod env otherwise what's the point to write something just to see a green circle.

If you're using Spring binstubs, but temporarily don't want commands to run through Spring, set the DISABLE_SPRING environment variable.

Yeap, noticed that too and I thought to use that for CI workflow, but then it would make devs use it for their runs, which I've tried to avoid. This PR (the commit with spring conditionally disabled) tries to make as little invasive changes as possible without changing any already existing workflows: spring is not nuked, it can be still used by devs (although it won't work properly anyway), it's even supported for most test suits (except integrations), no additional env variables must be set to run commands.

I'd love having code reloading working properly, but it seems it's quite complicated to make it work in Foreman (I might lack deeper knowledge about Rails internals though, so if anyone wants to fix that, please do. Fresh eyes make miracles). I disabled spring for integration tests since reloading takes too much time (although it shouldn't) causing timeouts, messes up constant ids, which leads to errors such as organization_obj.class <= Organization #=> false.

@ofedoren ofedoren force-pushed the rails-7.0 branch 2 times, most recently from 2f040d6 to 1a151be Compare November 7, 2024 14:11
config/application.rb Outdated Show resolved Hide resolved
config/boot.rb Outdated Show resolved Hide resolved
Without this patch Ansible-related scopes for Host::Managed.includes()
would look like:
[ { host_ansible_roles: :ansible_roles }, { ansible_role: [{ ansible_variables:
[:lookup_values] }] } ], which for some reason worked before Rails 7.
After this patch, it looks like:
[ { host_ansible_roles: { ansible_role: [{ ansible_variables:
[:lookup_values] }] } } ].
Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

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

Can we clear https://github.com/theforeman/foreman/blob/develop/config/as_deprecation_whitelist.yaml? I think those deprecations should now be resolved and will make CI fail on them. Plugins should also respect this config.

@ofedoren
Copy link
Member Author

Can we clear https://github.com/theforeman/foreman/blob/develop/config/as_deprecation_whitelist.yaml? I think those deprecations should now be resolved and will make CI fail on them. Plugins should also respect this config.

Sure, done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

2 participants