Bump rails from 6.1.7.8 to 7.1.3.4

[dependabot[bot]]

Bumps rails from 6.1.7.8 to 7.1.3.4.

Release notes

Sourced from rails's releases.

7.1.3.4

Active Support

• No changes.

Active Model

• No changes.

Active Record

• No changes.

Action View

• No changes.

Action Pack

• Include the HTTP Permissions-Policy on non-HTML Content-Types [CVE-2024-28103]

Active Job

• No changes.

Action Mailer

• No changes.

Action Cable

• No changes.

... (truncated)

Commits

• 19eebf6 Preparing for 7.1.3.4 release
• bd7c28a update changelog
• 1ac6d40 Sanitize ActionText HTML ContentAttachment in Trix edit view
• c7b9e0c include the HTTP Permissions-Policy on non-HTML Content-Types
• 747a03b Preparing for 7.1.3.3 release
• 260cb39 Upgrade Trix to 2.1.1 to fix [CVE-2024-34341][1]
• 6f0d1ad Preparing for 7.1.3.2 release
• c25f0fc Respect raise_on_missing_ in controller
• d73ed95 Preparing for 7.1.3.1 release
• 43037d8 update changelog
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[mogul]

I'm kind of baffled that this very blunt approach to upgrading is nevertheless passing tests...! I'd like to check with someone who knows Rails better than me before I merge this in, like @ryanwoldatwork or @rahearn... What do you say?

[mogul]

If I run rails app:update (leaving in selected customizations) then tests start failing immediately, even before I set the 7.1 defaults. Based on what I was going through with @rahearn last week it seems like it's not actually "upgraded" without that happening, so I think this will need more scrutiny. 🤔

[ryanwoldatwork]

Happy to pair with you on it tomorrow afternoon and get the 7.1 defaults in if you still have a need.

[mogul]

The team can opt into additional version-specific opinions/changes through update commands later.

Wait are you saying that I can update the rails gem and then simply opt not to do the app:update thing, and that's a legit way to run...?

[ryanwoldatwork]

Ya. Feature specs passing indicate to me the app is working accordingly with the updated version of Rails and other gems just fine. We should still review and understand what'd not be upgraded (eg: webpacker) with the 7.1 specific updates. And... what upgrade features, if any, are needed for user-features or the team's needs.

[mogul]

rails federal_register:find_sorns fails on this branch, and it looks like it's due to an outdated version of good_job. So I'm endeavoring to update good_job before I look further into this. This is where I got to.

[monfresh]

I would not entirely agree with this assessment. Running rails app:update is an important part of upgrading. Also, it is not advisable to go directly from 6.1 to 7.1. Rails upgrades should be performed incrementally. So first 6.1 to 7.0, then 7.0 to 7.1

I would highly recommend going through the official Rails Guides for upgrading: https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-6-1-to-rails-7-0

For example, note this aspect of upgrading from 6.1 to 7.0:

Before loading the schema for the first time in Rails 7.0, make sure to run rails app:update to ensure that the version of the schema is included in the schema dump.

In addition, running rails app:update creates a file that allows you to turn on new Rails 7 features one by one in production. Issues with some of these will probably not be caught by specs alone. The file will be named something like config/initializers/new_framework_defaults_7.0.rb and it has a bunch of settings commented out by default. Each setting that's relevant to the app must be turned on one by one and deployed to production one at a time to make sure everything is fine. Then, you can turn on the next one, deploy it, and test, and repeat until you've turned them all on.

https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#configure-framework-defaults

[mogul]

That's 2 vs 1, so I'll finish updating good_job and then try to rebase my existing Rails 7.0 branch. Closing this one!

[dependabot[bot]]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.