Upgrade and Stuff to Do

[carlost]

Stuff to do:

Need to split this into a lot of separate issues

Upgrade Stuff That Needs To Be Done In Order

• Upgrade Ruby to 2.7.x
• Upgrade Rails 5.0 -> 5.1
• Upgrade Rails 5.1 -> 5.2
• Upgrade to Ruby 3.0.x
• Upgrade to Rails 5.2 -> 6.0
• Upgrade Rails 6.0 -> 6.1
• Upgrade Ruby 3.3.x
• Upgrade Rails 6.1 -> 7.0
• Upgrade Rails 7.0 -> 7.1
• Upgrade Ruby to 3.4.x
• Upgrade Rails 8.0
• Remove devise and use the rails 8 authentication
• Add in the Hotwire stack (turbo/stimulus)
• Convert all js to stimulus and make it modern

Other Tasks That Can Be Done In Any Order

• GitHub actions for ci/cd (partially tracked by CI pipeline for AWBW #55)
• Issue templates
• PR templates
• License File (MIT)
• Code of Conduct (@sampart)
• Contributing File
• Search repo/git for secrets/keys/passwords/etc: https://github.com/rubyforgood/awbw-dashboard/issues/14
• Update/Modernize Readme
• Add in rubocop-rails-omakase (done in Rubocop rails omakase #602 )
• Add in brakeman (done in Add a better CI pipeline with security scans. #110 )
• Add in bundle-audit (done in Add a better CI pipeline with security scans. #110 )
• Any others we're missing
• Audit Gemfile
• Add tests
• Decide how js/assets will be done in rails 8
• Remove Capistrano and switch to Kamal
• Move from paperclip to active storage (Requires Rails 5.2 or higher) (tracked by Migrate from Paperclip to ActiveStorage (Rails 5.2 or higher) #17 )
• Evaluate if we can move from ckeditor to action text
• Tests, tests, tests
• General cleanup - lots of stuff everywhere
• Can we drop monthly_reports & workshop_logs tables from schema

General notes:

• bin/rails app:update
• should we just skip webpacker?
• official rails upgrade guide starting at 4.2 to 5: https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-4-2-to-rails-5-0

[maebeale]

@carlost Most of these are their own tickets now, yes? Do you have an easy sense of which of these should become new tickets, even if we keep this one for taking progress?

[carlost]

i am not a fan of these omnibus issues

• I think there are separate issues for the Rails upgrades
• "Remove devise and use the rails 8 authentication" ... are you sure you want to do that?
• "Add in the Hotwire stack (turbo/stimulus)" & "Convert all js to stimulus and make it modern". sounds good, probably want something a little more impact oriented than "add a gem" :) The issues related to vue and cocoon might be a good place to address this.
• "Search repo/git for secrets/keys/passwords/etc" should be done already
• A number of these are CI related, like "Add in brakeman". @lenikadali Do you want to open up separate items for these (assuming the HE or HT workflows support these things ... which i bet they do).
• "Remove Capistrano and switch to Kamal" ... this has been obviated by deploying to an env that is docker based and directly tied to our GH repo
• "Move from paperclip to active storage (Requires Rails 5.2 or higher)" is tracked as a separate issue
• "Add tests" and "Tests, tests, tests" can be ignored in light of the existing "system spec" issues
• "General cleanup - lots of stuff everywhere" is so vacuous that you can just ignore it

... i suspect that I missed some of these. that list is too long and it is too late.

[lenikadali]

• A number of these are CI related, like "Add in brakeman". @lenikadali Do you want to open up separate items for these (assuming the HE or HT workflows support these things ... which i bet they do).

@carlost Hmmm... I think that this could be separated into adding security tooling to the CI pipeline and adding lint tools to the pipeline. That being said, I am aware that for some projects having the tickets be fine-grained (e.g. Add brakeman) may good for when it doesn't go smoothly and some time gets spent on troubleshooting, which ends up being unaccounted for.

Edit: I think let's do separate items. It may make it harder to review and/or troubleshoot if we batch all the changes into one PR e.g. for the CI related stuff.

[lenikadali]

Following the initial review comments of the Add dependency auditing to AWBW PR that suggest we wait until the app is upgraded up to Rails 8 before merging it, it may helpful to identify what parts of the CI/CD pipeline can be done before the upgrade is complete.

One idea I had was to add the different workflows as is and just comment them out. Another way to handle this would be to add the files but name them in such a way that they don't get run for now and then name them appropriately once we're ready to start running pipelines on the repository code.

The principle behind this as mentioned here and here is that we want to conform to what other Ruby for Good projects are doing and avoid accidentally diverging in case it takes a while to enable a CI/CD pipeline.

Happy to hear feedback/other ideas from fellow contributors 😇

[maebeale]

ooo, love these options @lenikadali <https://github.com/lenikadali> ! I think the commented-out version is a little cleaner, but would be open to either.

…

On Wed, Sep 10, 2025 at 3:11 PM Leni Kadali ***@***.***> wrote: *lenikadali* left a comment (rubyforgood/awbw#3) <#3 (comment)> Following the initial review comments of the Add dependency auditing to AWBW PR <#76> that suggest we wait until the app is upgraded up to Rails 8 before merging it, it may helpful to identify what parts of the CI/CD pipeline can be done *before* the upgrade is complete. One idea I had <#55 (comment)> was to add the different workflows as is and just comment them out. Another way to handle this would be to add the files but name them in such a way that they don't get run for now and then name them appropriately once we're ready to start running pipelines on the repository code. The principle behind this as mentioned here <#55 (comment)> and here <#55 (comment)> is that we want to conform to what other Ruby for Good projects are doing and avoid accidentally diverging in case it takes a while to enable a CI/CD pipeline. Happy to hear feedback/other ideas from fellow contributors 😇 — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2BMBPGVLF4DJ5QDV4FJDL3SBZVTAVCNFSM6AAAAAB5U6CVO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENZWGE4TSOBQGU> . You are receiving this because you commented.Message ID: ***@***.***>

[maebeale]

added 'blocked' label just so no one picks this up

[maebeale]

we've either completed everything or moved things to their own issues. woot!