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

feature/APPEALS-28925-33581 - Update to Rails 6.1 & Replace 'multiverse' with standard Rails multi-DB configuration #21736

Conversation

jcroteau
Copy link
Contributor

@jcroteau jcroteau commented May 23, 2024

🎗️ Reminder:

After department-of-veterans-affairs/caseflow-commons#225 is merged, I need to lock caseflow ref to appropriate hash and update Gemfile.lock (bundle update --conservative caseflow).


Resolves:

Note: It was necessary to combine the changesets for both of the above stories into a single PR, as they are co-dependent in terms of passing the test suite.


TBD

…esent_boolean_as_integer`

This will have no implications for Caseflow, since we are only using the `sqlite3`
adapter nominally for the `demo_vacols` database, which is not actually being used
in our demo environments (demo environments are deployed as `development` envs).
Removes unneeded gems `bourbon` and `neat`, which were causing
a sub-dependency conflict on `thor`.
The default value is safe to assume here. There is a possible edge-case
for recursive associations having the same name as the model, but
we do not have any such associations in Caseflow.

For more background, see
https://lilyreile.medium.com/rails-6-1-new-framework-defaults-what-they-do-and-how-to-safely-uncomment-them-c546b70f0c5e#9072
We're not currently using ActiveStorage in Caseflow, so it
is safe to just assume the default here.
The default jitter is probably safe, however, I'm not 100% sure that we
don't have any jobs that need to be requeued with exact wait times. So
we let's override this for now to stay on the safe side.
…nated`

We're not currently using `throw :abort` within any `before_enqueue`/`before_perform` 
callbacks on existing Caseflow jobs, so the default should be fine here.

For more background, see
https://lilyreile.medium.com/rails-6-1-new-framework-defaults-what-they-do-and-how-to-safely-uncomment-them-c546b70f0c5e#4c60
…tion`

This setting controls the `SameSite` optional attribute for the
`Set-Cookie` header.

`SameSite=Lax` means that the cookie is not sent on cross-site requests,
such as on requests to load images or frames, but is sent when a user is
navigating to the origin site from an external site (for example, when
following a link). This is the default behavior if the SameSite attribute
is not specified.

`Lax` is currently the default assumed by both Chrome and Edge browsers
when this attribute is left unspecified, so assuming this value
should be sensible. It allows us to have our cake (blocking CSRF attacks)
and eat it too (providing a logged-in experience when users navigate to
Caseflow  across origins).

For more background, see
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value
- https://lilyreile.medium.com/rails-6-1-new-framework-defaults-what-they-do-and-how-to-safely-uncomment-them-c546b70f0c5e#1f15
…imes`

We're not using `ActiveSupport::TimeZone.utc_to_local` anywhere,
so the default is safe to assume here.
The default should be safe to assume here, as we do not do any
role or shard switching on database connections.

For more background, see
https://lilyreile.medium.com/rails-6-1-new-framework-defaults-what-they-do-and-how-to-safely-uncomment-them-c546b70f0c5e#8007
…orms`

We don't use the `form_with` helper anywhere, so this behavior change is
inconsequential for us, and we can safely assume the new default.
We do not use ActiveStorage, so the default is safe to assume here.
We do not use ActiveStorage, so the default is safe to assume here.
We don't use ActionMailbox, so the new default is safe to assume here.
We do not use ActionMailbox, so the default is safe to assume here.
We're not using `ActionMailer::MessageDelivery #deliver_later` anywhere,
so the default is safe to assume.
This flag can be safely uncommented. Browsers that support Link
headers will get a performance boost. Browsers that don’t will
ignore them.

We override in `development` environments to avoid an edge case
leading to an HTTP response header overflow.

For more background, see
https://lilyreile.medium.com/rails-6-1-new-framework-defaults-what-they-do-and-how-to-safely-uncomment-them-c546b70f0c5e#3679
This deprecation warning was addressed by the following
PR, but we forgot to add it to the list of disallowed
deprecation warnings:

#21614
Task `rake routes` has been replaced with `rails routes`
…ent_type` 

`ActionDispatch::Response#content_type` now returns the full Content-Type header
Group DB configs by environment in anticipation of
reformatting for Rails 6+ multi-DB configuration.
After migrating to the Rails 6+ native multi-database configuration,
the behavior of some DB management tasks, such as `rake db:migrate`
changed such that they now act on ALL databases and not just the
primary database. So we must replace the invocations of these
tasks with their new, database-specific counterparts.
Now that we have fiully transitioned to Rails-native
multi-database support, we are no longer reliant on
the 'multiverse' gem and can remove it.
After transitioning to Rails-native multi-DB support,
the behavior of some DB tasks changed such that they will now
act on ALL databases and not just the primary database
(ex. `rake db:migrate` will now migrate ALL databases).

To avoid accidents, we re-define these tasks here to no-op
and output a helpful message to redirect developers toward
using their new database-specific counterparts instead.
Explicitly clear any generated database tasks for the vacols DB.

Once on Rails 7+, we can instead add the `database_tasks: false`
option to the `database.yml` to permit connection to the vacols
database without generating database tasks for it:

https://github.com/rails/rails/blob/984c3ef2775781d47efa9f541ce570daa2434a80/guides/source/active_record_multiple_databases.md?plain=1#L203-L219
Instead of performing a bunch of hard-to-maintain `sed` gymnastics
to modify the existing 'test' environment, let's create a new
'make_docs' environment (based off of 'test') and configure it
appropriately for use by the 'Make-docs-to-webpage' GH workflow.
@jcroteau jcroteau changed the base branch from master to DO-NOT-MERGE/prereqs-for-update-to-rails-6-1 May 23, 2024 22:07
config/environments/make_docs.rb Dismissed Show dismissed Hide dismissed
@jcroteau jcroteau changed the base branch from DO-NOT-MERGE/prereqs-for-update-to-rails-6-1 to master May 23, 2024 22:10
@jcroteau jcroteau changed the base branch from master to DO-NOT-MERGE/prereqs-for-update-to-rails-6-1 May 23, 2024 22:10
Copy link

codeclimate bot commented May 23, 2024

Code Climate has analyzed commit 38efb92 and detected 6 issues on this pull request.

Here's the issue category breakdown:

Category Count
Duplication 2
Bug Risk 1
Style 2
Performance 1

View more on Code Climate.

@jcroteau
Copy link
Contributor Author

Superseded by #21737

@jcroteau jcroteau closed this May 23, 2024
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