Upgrade Mastodon: Difference between revisions

Revision as of 23:39, 19 September 2023

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 fix.
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

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:

@@ Line 14: / Line 14: @@
 ** 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 <code>glitch-soc-main</code> branch, which will then be overwritten on the next fork fix.
-*
+* Merge <code>dev</code> into <code>merge-upstream</code> 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 <code>merge-upstream</code> 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 <code>dev</code>, [https://github.com/NeuromatchAcademy/mastodon/compare/dev...NeuromatchAcademy:mastodon:merge-upstream Create a pull request] from <code>merge-upstream</code> to <code>dev</code>. Otherwise just merge <code>merge-upstream</code> to <code>dev</code>
+** We do this additional step before merging to main because we might have collected some hacks or additional code in <code>dev</code> from some other branches before deploying (and generally we want to play the upstream over dev)
+* Merge <code>dev</code> to <code>main</code>
 == Discord ==