AP-588 Upgrade Rails to 8.0.x

[steve-sullivan]

Upgrade Rails and dependencies to 8.0.x

• Upgrade Rails to 8.0.5
• Upgrade omniauth-cas to 3.x and add CSRF protection
• Update Puma, RSpec, RuboCop, and Berkeley Library gems
• Fix Rails 8 changes (ActiveRecord connection pool, status codes)
• Update auth for OmniAuth 2
• Fix CI (db task + secret_key_base requirement)

[anarchivist]

generally looks good - rw+c. most of my comments are minor. you might want to ask Anna to look at this, too.

[awilfox]

This looks mostly good, just a few nits. However, it looks like rails app:update wasn't run, similar to what happened at the beginning of BerkeleyLibrary/UCBEARS#21. Can you make sure that's run and the configuration files are updated appropriately? I described how to do that in the UCBEARS MR.

[awilfox]

When we upgraded Framework to 8.0, the suggested way to do it was to use verify! on the connection object. We also needed to add ActiveRecord::DatabaseConnectionError to the rescue block, but I'm not sure if that's because of verify! or because in general Rails 8 can raise that.

Suggested change

	ActiveRecord::Base.connection_pool.with_connection(&:active?)
	rescue PG::ConnectionBad
	ActiveRecord::Base.connection.verify!
	rescue PG::ConnectionBad, ActiveRecord::DatabaseConnectionError

I don't mind doing it the way already here; I just haven't seen it before. (will this raise if there are no active connections, or just return nil?)

[steve-sullivan]

Nice catch - I've updated to use verify! instead of active!

[awilfox]

Should we be moving this to 3.3.11 as well?

[steve-sullivan]

So do you think it's worth pinning the base image to 3.3.11?

Right now:
FROM ruby:3.3-slim AS base

I could pin it to 3.3.11, but then future bumps would need to be manually updated.

[anarchivist]

This is a little complicated, but we shouldn't change the Dockerfile.

In practice, we should be updating the Ruby version in the Gemfile.lock (or ship with a .ruby-version file), but it doesn't really have too much of an effect here. IIRC, this specifies the version that bundle was run under.

If we rebuild the image (e.g., after a merged new pull request), it will fetch the latest tag of ruby:3.3-slim, which updates the Ruby patch version under the hood.

[steve-sullivan]

Weird, yeah, my container was already running 3.3.11, but the lockfile wasn't updating. Finally did with this command:
docker compose run --rm app bundle update --ruby

[awilfox]

They've already snuck out another release while this was being worked on!

Suggested change

	gem 'rails', '~> 8.0.4'
	gem 'rails', '~> 8.0.5'

[steve-sullivan]

Those sneaky guys... Updated to 8.0.5!

[awilfox]

Do we want to test the Rails secrets stuff here like we do in Framework?

See BerkeleyLibrary/framework@6cf75564ef, specifically .github/workflows/build.yml and docker-compose.ci.yml. This makes a "real" (throwaway) secret, and that ensures the app is going to read it from the correct place in production.

[steve-sullivan]

I tried to shoe-horn that kind of test stage into the build.yml, but looks like it would take a little more work, galc-ui setup is a bit different than framework... so reverted back to the secret_key_base->dummy.

[awilfox]

We're quite close! Luckily there aren't too many new configurations it found for 8.0. I'm not sure about 7.1 and 7.2; you may need to step each one of those as well.

• 7.1
• 7.2

You don't need to do each one, since some of them are obviously not going to affect us (old IE support and the like). The main ones I'm concerned about from 7.1 and 7.2 are the Postgres adaptor settings and YJIT.

[awilfox]

It would be preferable to use the initialiser to test each new configuration, and assuming each one works fine, to change this to 8.0.

Suggested change

	config.load_defaults 7.0
	config.load_defaults 8.0

[awilfox]

Yes, exactly this.

[awilfox]

To be clear, you can download the 7.1 and 7.2 files I linked above and put them in config/initializers/ and perform the same procedure as is described in the 8.0 file.