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

Upgrade ruby and rails #749

Open
wants to merge 18 commits into
base: dev
Choose a base branch
from
Open

Upgrade ruby and rails #749

wants to merge 18 commits into from

Conversation

fosterfarrell9
Copy link
Collaborator

@fosterfarrell9 fosterfarrell9 commented Feb 22, 2025

Note: This PR has a "best before" date: 2025-03-31, see here.

This PR upgrades Ruby to 3.3.7 and Rails to 7.2.2.1 (and in particular resolves #611 and goes most of the way for #709), and some gems that needed an upgrade in order to make the Rails upgrade work. So far, it seems to work mostly nicely. Several deprecation warnings were shown; I fixed them all except one (see below),
and some unit tests are failing (see below).

Notes for the reviewer:

  • I let the app:update script overwrite our puma.rb file which seemed quite out of date compared to the current standard one. One notable difference is the handling of the pid file. Before, it was
ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }

Now, it is

# Specify the PID file. Defaults to tmp/pids/server.pid in development.
# In other environments, only set the PID file if requested.
pidfile ENV["PIDFILE"] if ENV["PIDFILE"]

On partiulcar, if we need the PID file in production, we should set an environment variable. I am not sure: We have

echo "Ensuring no stale server pid file is present"
rm -f tmp/pids/server.pid

in production/entrypoint_worker.sh.

  • We still have files related to a "development" environment (and if you search in our codebase, you will find several occurences of "development" referring to a "development" environment. Do we need that? All our development takes place in docker_development .
  • Rails 7.2 standard production.rb ccontains the line config.force_ssl = true. I added it, but put it in a comment. We should find out what happens if we uncomment it.
  • It appears that the standard in Rails 7.2 is that in a production console you can onbly see the id of database entries, nothing more. I overrode this in production.rb via
config.active_record.attributes_for_inspect = :all
  • In docker_development.rb I added the following lines wich come form the current Rails default devlopment file:
  # Raise error when a before_action's only/except options reference missing actions.
  config.action_controller.raise_on_missing_callback_actions = true

  # Apply autocorrection by RuboCop to files generated by `bin/rails generate`.
  # config.generators.apply_rubocop_autocorrect_after_generate!

I think the first one makes sense, and the second one should remain a comment since we have our own rubocop thing going on.

  • We still get this warning
DEPRECATION WARNING [legacy-js-api]: The legacy JS API is deprecated and will be removed in Dart Sass 2.0.0.
More info: https://sass-lang.com/d/legacy-js-api

See here. It appears we could get rid of it if we upgrade sass-loader to v16 in our yarn modules, but do we want that? It seems that vite offers a better solution, see here.

  • I am a little confused about the failing unit tests. The error messages say
Failure/Error:
  expect do
    UserCleaner.new.send_additional_warning_mails
  end.not_to have_enqueued_mail(UserCleanerMailer, :pending_deletion_email)

StandardError:
  To use HaveEnqueuedMail matcher set `ActiveJob::Base.queue_adapter = :test`

so this seems to refer to this. But in config/environments/test.rb we already set

config.active_job.queue_adapter = :test

Update: I guess the problem is in config/initializers/active_job.rb where we set (for all environments)

Rails.application.config.active_job.queue_adapter = :sidekiq

which probably overrides the :test setting. Do we have tests (unit or cypress) that rely on sidekiq? If not, we could just do a conditional here.

  • I checked the things mentioned in [Future] Upgrade to Rails 7.2 #611 and did not see any more deprecation warnings. Concerning the active_support.cache_format_version: I think we should be able to safely change this in production now (which happens automatically in this PR since we use the Rails 7.2 framework defaults in application.rb).

@fosterfarrell9 fosterfarrell9 changed the title Upgrade/ruby and rails Upgrade ruby and rails Feb 22, 2025
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.

1 participant