ci: replay migrations against a real Postgres, replacing the dead Supabase check - #498
Merged
Conversation
…abase check The "Supabase Preview" check has never validated anything. Two stale dashboard integrations are wired to this repo, and neither can provision: one 404s in four seconds with "Postgres config not found", the other hangs forever on "Waiting for branch action run to complete" because Supabase Branching needs a supabase/config.toml that this repo has never had. It also only fires when supabase/migrations/ changes, so most PRs show no Supabase check at all and the red X looks intermittent rather than permanent. The upshot is that every migration in this repo has shipped unexecuted by CI — 39 files whose first real run is against production data. This job does what that check only claimed to. It boots a throwaway Postgres with the Supabase CLI and replays every migration from nothing, in order, failing on the first statement Postgres rejects. No secrets, no Supabase account, no paid plan: the database runs in a container on the runner. It then asserts a handful of resulting objects exist. Every DDL statement in this repo is IF NOT EXISTS-guarded so the files can be re-run safely, and that same guard turns a typo'd object name into a silent no-op with a green checkmark — so "no error" is not on its own evidence that anything was built. config.toml is deliberately minimal. It is what the CLI needs to recognise a project directory, not a copy of the hosted project's settings, which stay in the dashboard rather than becoming a second source of truth that drifts. Its major_version is the CLI default and should be aligned with the live project's Postgres version. The dashboard integrations still need disconnecting by hand; that cannot be done from the repo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Temporary. A green check that cannot go red is exactly the failure this PR is replacing, so assert something false once and watch CI.
Run 31579334056 went red with the deliberate assertion in place, so a RAISE in verify-schema.sql does fail the job. Recorded in the file.
supabase db query --file is one prepared statement, so a second top-level DO fails with 'cannot insert multiple commands'. Documented.
ArnasDon
marked this pull request as ready for review
August 12, 2026 08:54
Owner
Author
|
Out of draft — the job is green and, more to the point, proven able to go red. What CI established (not assumed):
Runtime is ~1m45s, and it only fires on Two caveats:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft while I confirm the job goes green — I have no container runtime locally, so this is the first time it can actually run.
Replaces the
Supabase Previewcheck, which has never validated anything. See the commit message for the diagnosis; short version: two stale dashboard integrations, one 404ing and one hanging, and Branching needs asupabase/config.tomlthis repo never had. Every migration in this repo has shipped unexecuted by CI.This job boots a throwaway Postgres with the Supabase CLI, replays every migration from nothing, and then asserts a few of the resulting objects exist (the DDL here is all
IF NOT EXISTS-guarded, so "no error" alone doesn't prove anything got built). No secrets, no Supabase account, no paid plan.You still need to disconnect the two dashboard integrations by hand — Integrations → GitHub in the Supabase dashboard. That can't be done from the repo, and until it is, the dead check keeps appearing alongside this one.
🤖 Generated with Claude Code