The GitHub integration decides whether a pull request touches the schema once, at around PR-open time. If the opening commit changes nothing under supabase/, the PR is marked ignored — and a migration added in a later commit doesn't trigger provisioning. The bot states the behaviour in each comment it posts: tasks run on every commit, but only new migration files are pushed, and the suggested remedy is to close and reopen the pull request.
On a private repo using Git-based branching, two PRs on the same day:
supabase/ file. The bot commented about 80 seconds later that the PR was ignored, no changes detected in the supabase directory. About an hour after that, a later commit added a real migration under supabase/migrations/. The bot's comment had identical created_at and updated_at — never re-posted or edited — and list_branches on the parent project showed no branch for that PR more than an hour after the migration landed.status: FUNCTIONS_DEPLOYED.Adding a migration part-way through a PR is an ordinary way to work: a reviewer asks for a column, or a scope correction turns out to need one. Any project that gates CI on the branch database — running an end-to-end suite against it, for example — depends on the branch existing, so a PR that takes this shape has to be closed and reopened before it can go green. That works, but it churns the preview through a teardown and rebuild for what is a one-line evaluation decision upstream.
POST /v1/projects/{ref}/branches has no pr_number parameter, and pr_number is the only field linking a branch back to its pull request. Falling back to matching on git_branch isn't safe — across a fork or a renamed head it could resolve a PR to another PR's database. So a CI script can't create the branch itself and have it resolve correctly; only the integration can.
synchronize event, not only near PR open.Either one would resolve it. This isn't specific to my setup: any repo combining Git-based branching with a migration-aware CI gate hits it the same way.
Related: #47427, #41543.
Matt McFadden suggests improvements to the GitHub integration for handling schema changes in pull requests. Currently, the integration only evaluates schema changes at PR open, which can miss migrations added later. He proposes re-evaluating on every synchronize event or providing an API to force re-evaluation, as current limitations require closing and reopening PRs to trigger provisioning.