chore: fix migration conflicts

[mattkrick]

Description

The most frequent reason for a failed release is a failed predeploy due to conflicting migration names. For example, an older PR gets merged after a newer PR was already merged & pushed to prod, invalidating the migration run order.

This PR stops that by making sure the PR doesn't include any migrations that predate the latest migration on master.

DEMO

If you have no migrations in your PR, you get this

If you have 1 valid migration in your PR, you get this

If you have 1 migration and it predates the latest migration on master, you get this

If you have 2 migrations in your PR you should consolidate or break apart your PR, so you get this

[Dschoordsch]

This will only catch some of the cases. If I have 2 PRs with conflicting migrations, both will pass the build pre-merge, but might cause an issue post merge as they're not re-verified after each master change.
I think we could only reliably check this on master post-merge.

[Dschoordsch]

+1 I'm not a fan of this restriction. If you know the number of migrations, you can do

FIRST_NEW_MIGRATION=$(ls packages/server/postgres/migrations | tail -n $NEW_MIGRATION_COUNT | head -n1)

[Dschoordsch]

After thinking about it, I think I would prefer if we could just check master that it's in the correct order. I think something along the lines of this

#!/bin/bash

PREV_COMMIT=$(git rev-list HEAD | tail -n 1)
PREV_FILE=''
for F in packages/server/postgres/migrations/*.ts; do
  CURR_COMMIT=$( git log --diff-filter=A --pretty=format:"%H" -- "$F")
  git merge-base --is-ancestor $PREV_COMMIT $CURR_COMMIT > /dev/null
  if [ $? -ne 0 ]; then
    echo "$PREV_FILE was added after $F but has a smaller timestamp"
  fi
  PREV_COMMIT=$CURR_COMMIT
  PREV_FILE=$F
done

This needs some cleanup though, or we make sure to only consider all files after the last failure

[mattkrick]

We should probably break this out into its own action. That way it could run when the PR gets opened & re-run whenever a commit to master gets pushed. I'll toy around a bit more!

[mattkrick]

omg i don't think it's possible to trigger a workflow when the base branch gets updated https://github.com/orgs/community/discussions/64119

i found a solution.
if we require that PRs be up to date before merging, then before a PR gets merged, they'll have to merge master into it & that will trigger a new action... this is safe, but it also really sucks because that means we can't merge 2 PRs back to back.
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging