[Testing 16] ci: run the RLS/stack integration suite on every PR - #256
Open
amal66 wants to merge 1 commit into
Open
[Testing 16] ci: run the RLS/stack integration suite on every PR#256amal66 wants to merge 1 commit into
amal66 wants to merge 1 commit into
Conversation
|
|
amal66
force-pushed
the
olp-pr/stack-tests-ci
branch
from
July 25, 2026 21:31
bfec767 to
ce4b460
Compare
The gated stack tests (backend/src/__tests__/integration/*.supabase.test.ts) prove the deny-all RLS firewall and the auth<->API contract against a real local Supabase stack, but no CI trigger ever set the SUPABASE_TEST_* env vars, so they silently self-skipped on every PR. Add a workflow that boots the stack on the runner (supabase CLI pinned, minimal service set: db, auth, rest, kong), bootstraps the database the way backend/scripts/test-stack.sh does, and runs the suite. No secrets: everything is local to the runner. The bootstrap loads schema.sql and then applies every dated migration on top in filename order, which doubles as a schema-drift smoke test: the snapshot and the migrations must apply cleanly together. Running it surfaced five migrations that could not apply on top of the current schema.sql — three whose backfills read documents columns that later migrations moved to document_versions, and two overview RPCs whose return row type `create or replace` cannot change. Guard the backfills on the historical columns' existence and drop-before-create the RPCs (the pattern 20260703_02 already uses); behavior on era deployments is unchanged, and the full sequence now applies cleanly end to end (verified locally: fresh stack, schema + 44 migrations, 5/5 stack tests green). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
amal66
force-pushed
the
olp-pr/stack-tests-ci
branch
from
August 3, 2026 01:57
ce4b460 to
6f4f321
Compare
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
2 participants
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.
What this fixes
Mike already has integration tests that check the two security properties that matter most for a legal tool: that the database refuses to hand rows to browser clients (the "deny-all" row-level security firewall), and that login tokens resolve to the right user through the backend's auth path. But those tests only run against a real local Supabase stack, and nothing in CI ever started one — so on every PR they quietly skipped themselves. A change that broke RLS could have merged with a green checkmark.
This PR adds a
Stack testsworkflow that boots a disposable Supabase stack on the CI machine itself, loads the database schema, and runs that suite on every PR and every push to main. No accounts, no secrets, nothing leaves the runner — the stack is created and destroyed inside each CI run. Only the services the suite touches are started (db/auth/rest/kong), keeping the job fast.A bonus safety property: schema-drift detection
The workflow builds the database by loading
schema.sql(the fresh-install snapshot) and then applying every dated migration on top, in order. That means every PR now also proves the snapshot and the migrations still fit together — if someone editsschema.sqlwithout a matching migration (or vice versa), CI fails before a fresh deployment can.This paid off immediately: five existing migrations did not apply cleanly on top of today's
schema.sql— three old backfills readdocuments.*columns that a later migration moved todocument_versions(they're now guarded on column existence, so real, older deployments behave identically and fresh-snapshot databases just skip the backfill), and two overview RPCs usedcreate or replacewhere the function's return shape had changed (nowdrop function if existsfirst — the exact pattern the later migrations in the series already use, and those later migrations re-create the final shape, so the sequence converges).Verified locally end to end: fresh stack →
schema.sql→ all 44 migrations → all 5 stack tests passing.Maintainer action required
Once this job has run green on a PR or two, please make it mandatory: Settings → Branches → branch protection rule for
main→ under "Require status checks to pass before merging" add theStack testsjob. Until you do that, the job runs and reports, but a red result won't actually block a merge.🤖 Generated with Claude Code