feat: add ability to ignore version mismatch check

[jkaczmarek1]

What kind of change does this PR introduce?

It's currently a problem when you merge two PRs that include migrations, but firstly, you will merge newer, then you will get an error that the version is a mismatch.

What is the current behavior?

Mismatch error on db push command.

What is the new behavior?

With --ignore-version-mismatch flag, all missing migrations on remote will be pushed. It is not recommended to use that on a production project.

Additional context

This feature is designed to be used on internal projects. On production, I would recommend not to use --ignore-version-mismatch flag.

[sweatybridge]

With --ignore-version-mismatch flag, all missing migrations on remote will be pushed.

Are you sure this is desired behaviour because the order of migrations often matters.

In cases like these, I would expect the CI checks to fail on the newer PR because the base branch is outdated. I would suggest the following workflow instead:

1. Run db push --dry-run on each PR to check that migrations are in order
2. Require all PRs to be based on latest main branch
3. Update timestamp of rebased PR to latest

After that, the CI check in step 1 should pass. The rebased PR can then be merged to main branch and its migrations can be pushed.

[jkaczmarek1]

@sweatybridge I agree that often order of migration matters. But I have 4 developers, and frequently they are working on things that are not related. So on every PR I need to manually update timestamp on each migration because sometimes we have migrations that cannot be merged until fronted are prepared. That's why I added this feature as an additional flag, not as a default behavior.

[coveralls]

Pull Request Test Coverage Report for Build 5713199287

• 36 of 40 (90.0%) changed or added relevant lines in 4 files are covered.
• 5 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.09%) to 57.281%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
cmd/db.go	1	2	50.0%
cmd/migration.go	2	3	66.67%
internal/migration/up/up.go	31	33	93.94%

Files with Coverage Reduction	New Missed Lines	%
internal/gen/keys/keys.go	5	12.31%

Totals
Change from base Build 5688434740:	0.09%
Covered Lines:	4740
Relevant Lines:	8275

---

💛 - Coveralls

[sweatybridge]

I've updated this PR to handle the following situations separately:

1. A more recent migration version exists on remote but not local.

This should continue to throw an error because it means the local files are outdated.

$ supabase db push
Remote migration versions not found in supabase/migrations directory.

Make sure your local git repo is up-to-date. If the error persists, try repairing the migration history table:
supabase migration repair --status reverted 20230630154537

And update local migrations to match remote database:
supabase db remote commit

exit status 1

2. A local migration file is inserted before the last migration ran on remote database.

This is a common scenario faced by multiple devs working on separate features as described in this issue. The newly added --include-all flag allows these migrations to be applied.

$ supabase db push
Found local migration files to be inserted before the last migration on remote database.

Rerun the command with --include-all flag to apply these migrations:
supabase/migrations/20220810154537_full.sql

exit status 1