Rails Upgrade

[jillpe]

Summary

Do initial rail upgrade from 5.1.6 to 6.1

Acceptance Criteria

• [ ] upgrade rails and its dependencies: #21
• [ ] get bundler/gemfile working so that you can at least start the application
• [ ] Create tickets for other breaking functionality (ie: fix specs)

Screenshots or Video

Testing Instructions

Notes

watch out for protected attributes

Gem list

Handle separately

• [ ] bundle update 'blacklight_advanced_search', '~> 6.4.0'
• [ ] bundle update 'hydra-role-management', '~> 1.0'
• [ ] bundle update 'hyrax', '~> 2.9.0'
• [ ] bundle update 'rails', '~> 5.1.5'
• [ ] bundle update 'sidekiq'

Update first

• [x] bundle update 'activerecord-nulldb-adapter'
• [x] bundle update 'aws-sdk-codedeploy'
• [x] bundle update 'aws-sdk-s3'
• [x] bundle update 'bixby' # bixby == the hydra community's rubocop rules
• [x] bundle update 'capybara-screenshot'
• [ ] bundle update 'capybara', '~> 3.0'
• [ ] bundle update 'carrierwave', '~> 1.3'
• [ ] bundle update 'coffee-rails', '~> 4.2'
• [ ] bundle update 'curb'
• [ ] bundle update 'database_cleaner'
• [ ] bundle update 'devise-guests', '~> 0.6'
• [ ] bundle update 'devise'
• [ ] bundle update 'dotenv-rails'
• [ ] bundle update 'factory_bot_rails', '~> 4.0'
• [ ] bundle update 'faker'
• [ ] bundle update 'fcrepo_wrapper'
• [ ] bundle update 'httparty', '~> 0.21'
• [ ] bundle update 'jbuilder', '~> 2.5'
• [ ] bundle update 'jquery-rails'
• [ ] bundle update 'letter_opener'
• [ ] bundle update 'listen', '>= 3.0.5', '< 3.2' do we need to update past 3.2?
• [ ] bundle update 'mysql2', '~> 0.5.3'
• [ ] bundle update 'nokogiri'
• [ ] bundle update 'puma', '~> 4.3' updated to 6.3.0
• [ ] bundle update 'pry-byebug', platforms: [:mri, :mingw, :x64_mingw]
• [ ] bundle update 'rails-controller-testing'
• [ ] bundle update 'react-rails'
• [ ] bundle update 'redis', '~> 4.0'
• [ ] bundle update 'redlock', '~> 1.0' updated to 2.0.2
• [ ] bundle update 'rsolr', '>= 1.0'
• [ ] bundle update 'rspec_junit_formatter'
• [ ] bundle update 'rspec-activemodel-mocks'
• [ ] bundle update 'rspec-its'
• [ ] bundle update 'rspec-rails', "~> 3.7"
• [ ] bundle update 'rspec', "~> 3.7"
• [ ] bundle update 'sass-rails', '~> 5.0'
• [ ] bundle update 'selenium-webdriver'
• [ ] bundle update 'shoulda-matchers'
• [ ] bundle update 'simple_form', '5.0.0'
• [ ] bundle update 'solr_wrapper', '~> 2.1'
• [ ] bundle update 'turbolinks', '~> 5'
• [ ] bundle update 'uglifier', '>= 1.3.0'
• [ ] bundle update 'web-console', '>= 3.3.0'
• [ ] bundle update 'webdrivers', '~> 4.0'
• [ ] bundle update 'webmock', '~> 3.7'
• [ ] bundle update 'webpacker'
• [ ] bundle update 'xray-rails'
• [ ] bundle update 'bootstrap-multiselect-rails' currently at (0.9.9)

Don't update

• [x] bundle update 'bulkrax', git: 'https://github.com/samvera-labs/bulkrax.git', ref: '23efea3fd9d8d98746b73e570e0dc214ff764271'
• [x] bundle update 'hyrax-batch_ingest', git: 'https://github.com/samvera-labs/hyrax-batch_ingest'
• [x] bundle update 'pbcore', '~> 0.3.0'
• [x] bundle update 'sony_ci_api', github: 'WGBH-MLA/sony_ci_api_rewrite', branch: 'v0.1'
• [x] bundle update 'willow_sword', git: 'https://github.com/notch8/willow_sword.git'

[ShanaLMoore]

blocked by #21 - Shana to have a convo with Steven. Which tool is better and why? Prod dev is using bootboot.

[ShanaLMoore]

Implementation suggestions: per https://www.youtube.com/watch?v=eiQutUYn_9A

upgrade to the next minor version at a time (5.1 => 5.2 => etc), then upgrade to the next major version (=> 6.0.0). address and fix deprecation warnings.

• these don't need to be fixed all at once. change one file at a time for easier testing and PR reviews. fix 1 deprecation warning per ticket/PR.
  • make the application errors/fail if devs don't adhere to the new patterns. We just fixed a deprecation warning so without something to flag us, it's easier to revert back to the way the deprecation warning is warning us about. ref: https://blog.testdouble.com/posts/2023-04-24-stop-ignoring-your-ruby-and-rails-deprecations/
    • Also log in production: dual boot - main can either run the production version of rails (switch is off) or the target rails (when switch is turned on)
• install bootboot
• bundle update rails
• as soon as you get dual booting working (version toggle) and you can bundle a new version of rails, ship it off to production (main)
• to not bring things, you'll likely need to add conditionals throughout the code. If you see a lot of these, it's a code smell. a pattern that your team is used to => wack-a-mole ie:

- [backport](https://blog.testdouble.com/posts/2021-05-11-working-strategically-through-rails-upgrades/) strategy: 
  - take new things and backport it to the old version of rails that your app is using (ie: strong params). 
    - include module to cause app to error ie: 

Test Failure strategies - break it up:

• group failures

  • are they failing for the same reason or not?
  • could group by file, CI container, depends on application and the failures you're seeing. Goal is to find manageable chunks of code to fix and ship. incremental progress.

• ready for prod?

  • Try small experiments in prod like environments to see if the app is behaving as expected. (ie: staging) monitor sentry, etc
  • canary deploy method -> ship upgrade to 5% of traffic for 2 minutes. Pull it back after that's done. monitor dashboards and error monitoring tools to determine if it's ok to try the experiment again. fix, monitor and compare. ship out to 10% next for 2 mins, 10% for 5 mins, etc. repeat.

[ShanaLMoore]

example of gemfile + notes w Steven

if ENV['DEPENDENCIES_NEXT'] && !ENV['DEPENDENCIES_NEXT'].empty?
  # gem 'rails', '~>5.2'
  # hit every version
  # fix deprecation warnings => sql string to where or joins method should be wrapped in a call to arel.sql (per rails 6)
  # update all gems other than rails to the latest as possible to deploy smaller PRs of those changes
  # so that it's not like you upgraded rails and 30 gems and don't know which one was the issue
  # group the dependencies. big ones like hyrax, do them on their own. smaller ones can be grouped. 
  # this process makes it easier to test. 
  # at the end update rails. 
  # look up blog articles and release notes for each version for any gotchas and breaking changes => rails guides. 
  # some depdendecy upgrades will be blocked by a rails version, so this process will be repeated multiple times. 
  # active storage or new features? otherwise not much has changed in core rails
  # 
  # continual? ok to leave it indefinitely and use for upgrading any gems. 
  # deploy - ci can build different images, can deploy it to staging. deploy image during an offtime and roll back if needed. 
  # have devs work under next but test on current.
  # 

else
  # Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
  gem 'rails', '~> 5.1.5'
end

[ShanaLMoore]

this required us to upgrade the gemspec of hyrax-batch_ingest

ref: https://github.com/samvera-labs/hyrax-batch_ingest/pull/152

and sony_ci_api was switched to main instead of v1.0