Point Gemfile.next at Rails 7.2 (7.1 -> 7.2 hop)#69
Merged
Conversation
JuanVqz
force-pushed
the
chore/upgrade-rails-7.2
branch
4 times, most recently
from
76508a0 to
eefa412
Compare
Detection scan against rails-72-patterns.yml found zero matches across all high- and medium-priority patterns (transaction-aware jobs, show_exceptions symbols, params comparison, ActiveRecord::Base.connection, Migration.check_pending!, serialize syntax, fixture_path, query_constraints, mailer test args, autoload_lib syntax) -- this app's small surface and the recent secrets.yml removal already cleared the one pattern that would have hit (Rails.application.secrets, removed outright in 7.2). bundle_report compatibility --rails-version=7.2.3.1 reports 0 incompatible gems. Resolved cleanly with no conflicts. Verified on Gemfile.next: boot smoke test passes, full suite green (11 runs, 0 failures), rubocop/reek clean, rake assets:precompile succeeds in production mode, and a real HTTP smoke test of the upload -> HTML -> PDF flow against a running server.
JuanVqz
force-pushed
the
chore/upgrade-rails-7.2
branch
from
eefa412 to
58a1104
Compare
bundler-audit-production runs Heroku Postgres 16.13; local dev was still on 13. Note for anyone pulling this: the existing db_data volume was initialized by Postgres 13 and isn't readable by 16, so it needs a reset once via `docker compose down -v`.
Ruby matches Gemfile's "3.2.11". Node matches the version Heroku's nodejs buildpack resolved to (24.18.0, current LTS at deploy time) since package.json has no engines pin.
.ruby-version.sample (2.4.3) and .nvmrc (12.13.0) were years out of date and didn't match the Gemfile's ruby "3.2.11" -- bin/setup on a truly fresh clone (no pre-existing .ruby-version) would copy in the wrong Ruby version and bundle install would fail on the mismatch. Updated both to match Gemfile/.tool-versions. bin/dev is a plain rails server wrapper, not a Procfile.dev/foreman runner -- there's no separate asset-watch process to coordinate since Sprockets compiles JS/CSS on the fly in development.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this PR:
Description:
Now that #68 (Ruby 3.2 / Rails 7.1 groundwork) is merged into
main, this PR is rebased directly on top of it. It starts the next hop in the sequential upgrade path (Rails 7.1 → 7.2) plus a handful of dev-environment fixes uncovered while working on it:Gemfile.next'srailsconstraint to>= 7.2.0, < 7.3.0, resolving cleanly to 7.2.3.1 with no conflicts.show_exceptionssymbol values,paramscomparison,ActiveRecord::Base.connection,Rails.application.secretsremoval,Migration.check_pending!removal,serializesyntax,fixture_path,query_constraints, mailer test args,autoload_libsyntax) — zero matches. The one pattern that would have hit (Rails.application.secrets) was already cleared in Upgrade application to unblock infrastructure #68.bundle_report compatibility) reports 0 incompatible gems against 7.2.3.1.docker-compose.ymlto matchbundler-audit-production's actual Heroku Postgres version (was drifted)..tool-versionspinning Ruby (3.2.11, matching the Gemfile) and Node (24.18.0, matching what Heroku'snodejsbuildpack resolves to) for asdf users.bin/setupsamples:.ruby-version.sample(2.4.3) and.nvmrc(12.13.0) were years out of date and didn't match the Gemfile'sruby "3.2.11"— on a truly fresh clone,bin/setupwould copy in the wrong Ruby version andbundle installwould fail on the mismatch.bin/dev— a plainrails serverwrapper (noProcfile.dev/foreman needed, since there's no separate asset-watch process to coordinate; Sprockets compiles JS/CSS on the fly in development).This PR does not flip the app to Rails 7.2 as the default yet — it lands the dual-boot target so the version bump itself can be a small follow-up, same pattern as the earlier 6.1 → 7.0 and 7.0 → 7.1 hops.
Related links (if applicable):
N/A
How has this been tested?
What manual tests have been run?
rails runner) passes onGemfile.next(Rails 7.2.3.1).Gemfile.next(11 runs, 0 failures), rubocop and reek clean.rake assets:precompilesucceeds in production mode onGemfile.next.Gemfile.next.docker compose down -v && docker compose up --buildboots cleanly against Postgres 16.13 and the full test suite passes against it.