Repository navigation
ci(cli): publish config schemas to supabase.com from stable releases (CLI-2864) - #7397
Merged
Coly010 merged 4 commits intoOct 30, 2026
Conversation
…LI-2864) Stable releases copy the newest version of each schema in apps/docs/public/schemas to apps/www/public/schemas in supabase/supabase, opening or reusing a cli/schemas PR with auto-merge armed when a file changed. The publisher validates each schema first and refuses to write below a version supabase.com already serves. The clone/commit/PR flow moves into scripts/publish-pull-request.ts, shared with the CLI reference publisher. A failed publish turns the renamed "Publish to supabase.com" job red and posts to Slack.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🤖 AI Review
Adjudicated all six findings and merged two duplicate pairs. Confirmed a major frozen-schema safeguard bug, a minor notification gap, and a test-naming nit. Refuted the Slack rerun instruction concern.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| 🟠 MAJOR | apps/cli/scripts/publish-schemas.ts:110 |
correctness |
claude+codex | The frozen-version safeguard checks the reused publishing branch instead of the destination base, allowing changes to versions already frozen on master. |
| 🟡 MINOR | .github/workflows/release.yml:386 |
error-handling |
claude+codex | Publishing failures can escape Slack notification when the docs job terminates before exporting its report. |
| ⚪ NIT | apps/cli/scripts/publish-schemas.integration.test.ts:112 |
test-conventions |
claude | This subprocess-based suite uses the integration-test suffix despite the documented convention reserving that behavior for E2E tests. |
Refuted findings (kept for transparency, not posted as review comments)
.github/workflows/slack-notify.yml:111(operability): The Slack rerun instruction is insufficient because Re-run failed jobs may skip the publishing job under job-level continue-on-error.
Refuted: The message already directs the operator to rerun the specific job and links its workflow run. It does not instruct them to use Re-run failed jobs. The proposed clarification repeats the existing instruction; job-level continue-on-error does not prevent rerunning a named job.
Stats
Claude findings: 4 · Codex findings: 2 · Confirmed: 3 · Refuted: 1 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
…publish-schemas-to-supabasecom-from-cli-stable-releases
The publisher now reads served versions from origin/<base> rather than a reused cli/schemas checkout, and refuses when the branch changes any file other than the current versions. A docs job that never exports failed=false now counts as a failed publish for the Slack notice. The git-backed publisher suite moves to e2e with stale-branch coverage.
Contributor
CLI benchmark: no changes foundCommit
API calls: unchanged for all 7 commands. Binary size: 133.8 MB, unchanged. Details: timing ranges, API calls per command, slowest phasesTiming ranges
API calls per command
Slowest phasesNo command moved beyond noise, so there are no phase deltas. Comment |
Coly010
added a commit
to supabase/supabase
that referenced
this pull request
Oct 29, 2026
## Problem The Supabase CLI's config, project-config and `supabase.lock` JSON schemas declare `$id`s under `https://supabase.com/schemas/<name>/v<N>.json`, and editors such as Even Better TOML fetch them from the `$schema` URL. Nothing is served at that path yet, so those URLs 404. ## Solution - Adds `apps/www/public/schemas` with v1 of the three schemas. They're generated in supabase/cli, and from now on its stable releases open a PR here when one changes (supabase/cli#7397) - `/schemas/:path*` responses send `access-control-allow-origin: *` and `cache-control: public, max-age=3600`, so browser-based editors and validators can fetch them and a new release shows up within the hour. Covered in `next.config.test.ts` - `/apps/www/public/schemas/ @supabase/cli` in CODEOWNERS, so the CLI team reviews those release PRs - The folder is in `.prettierignore`. The CLI publishes these files byte for byte, so reformatting them here would show up as a change on every release ## Review instructions 1. Open `/schemas/config/v1.json` on the www preview 2. Check it returns the schema as JSON, with `access-control-allow-origin: *` and the cache header (`curl -sI <preview>/schemas/config/v1.json`) Closes CLI-2865
jgoux
approved these changes
Oct 30, 2026
Coly010
deleted the
columferry/cli-2864-publish-schemas-to-supabasecom-from-cli-stable-releases
branch
October 30, 2026 12:24
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
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.
Summary
Since #7366 the config, project-config and
supabase.lockschemas have$ids underhttps://supabase.com/schemas/, but nothing serves them yet. supabase/supabase#52509 sets upapps/www/public/schemasin supabase/supabase, and this publishes to it from every stable release.scripts/publish-schemas.tscopies the newest version of each schema inapps/docs/public/schemastoapps/www/public/schemason acli/schemasbranch in supabase/supabase. It only opens a PR (or reuses the open one) when a file changed, and arms auto-merge on it$idmatching the URL it'll be served from. Lower versions are never written, and it refuses to publish if supabase.com already serves a newer version or thecli/schemasbranch changes anything else, so a published version can't be modified--dry-runvalidates and prints what it would publish without touching supabase/supabase. Release dry runs pass itscripts/publish-pull-request.ts, shared withpublish-docs-spec.ts. The CLI reference publisher behaves the same as beforedocsjob is now "Publish to supabase.com" and runs both publishers, each without stopping the other. A failed publish adds an error annotation and a step summary line, turns the job red and posts to Slack (newpublish-failuremessage). The release itself still succeedsAuto-merge still waits on a code-owner approval, since supabase/supabase
masterrequires one and the releaser App can't approve its own PR. The schemas path is owned by@supabase/cli, so one of us approves and it merges itself. Making it fully hands-off would need the App added as a bypass actor on that ruleset.There's no
v*.xbranch at the minute, so no cherry-pick is needed.Linked issue
Closes CLI-2864