Upgrade Mastodon

Up to: Tech WG

Stages

History: Steps that were followed for Merging glitch + 4.2RC + our instance's features

all branches refer to those in NeuromatchAcademy/mastodon unless specified otherwise.

• Sync the glitch-soc-main branch to glitch-soc/mastodon:main: Open the branch page and click "sync fork"
  • If there are any local changes that make a conflict, they can be discarded - this branch is supposed to just be a local copy of the upstream main branch that doesn't reflect our local changes, we will handle that in the next step.

• Create a pull request from glitch-soc-main to merge-upstream
  • Resolve conflicts, ensuring that changes we have made locally are preserved when possible.
  • If it is not possible to preserve a hack, eg. because the relevant feature has been deprecated, update the corresponding feature page and include that in the pull request description
  • Don't try and fix failing tests here - that would edit the glitch-soc-main branch, which will then be overwritten on the next fork sync. NOTE from Manisha -- The glitch-soc-main branch had commits from merge-upstream even after syncing the the branch. So I created a new branch called glitch-clean-sync from glitch-soc's main branch. Let's keep this branch clean and not merge anything to this branch. Only use the sync feature. I also tried to follow the rest of the process but it seemed a bit complicated/unclear. I've tried to simplify it in a separate section above for glitch+4.2+our instance's features
• Merge dev into merge-upstream if necessary
  • It seems like this is the way glitch-soc does it, merge all from upstream masto into a branch from dev, then merge dev into the branch to ensure all glitch modifications go on top of the upstream? not exactly sure -jonny
• Fix any failing tests in the merge-upstream branch
  • Ruby Tests, One and Two step db migrations must pass, but linting failing is fine and normal
• If any changes were made after merging dev, Create a pull request from merge-upstream to dev. Otherwise just merge merge-upstream to dev
  • We do this additional step before merging to main because we might have collected some hacks or additional code in dev from some other branches before deploying (and generally we want to play the upstream over dev)
• Merge dev to main

Deploying

• Make a backup on the linode dashboard
• Check for any release-specific instructions and follow those! If you are doing an upgrade through several versions, make sure you follow those too!
  • Base masto: https://github.com/mastodon/mastodon/releases
  • Glitch docs (mostly just the same as base masto): https://glitch-soc.github.io/docs/

Otherwise, in general...

Switch to the mastodon user and change to the masto directory

sudo su mastodon 
cd ~/live

Fetch changes

git pull

Install dependencies

bundle install
yarn install --frozen-lockfile

Run pre-deployment database migrations

RAILS_ENV=production SKIP_POST_DEPLOYMENT_MIGRATIONS=true bundle exec rails db:migrate

Precompile assets

RAILS_ENV=production bundle exec rails assets:precompile

Restart services (you may have to switch back to your original user with exit because the mastodon user cannot sudo for obvious reasons)

sudo systemctl reload mastodon-web
sudo systemctl restart mastodon*

Run post-deployment database migrations

RAILS_ENV=production bundle exec rails db:migrate

Discord

sneakers-the-rat#techwg-ops23-05-20 05:46:32

Tech WG/Ops Diary#23-05-19: We are attempting to Upgrade Mastodon to 4.1.2 and also merge in Exclusive Lists, wish us luck.

We begin with what is probably the worst way to do it based on the conversation in <#1049184335514828860> , specifically:

• main -> dev,
• upstream -> dev,
• dev -> pr,
• pr -> dev,
• dev -> main

https://discord.com/channels/1049136631065628772/1049184335514828860/1109355378178789396

mannazsci#techwg-ops23-10-01 07:44:40

Tech WG/Ops Diary#23-10-01 I am ready to deploy v4.2 but I encountered a few issues while following the process mentioned in Upgrade_Mastodon. I'll update the wiki with the steps I took.