chore: production deploy#5329
Merged
Merged
Conversation
## TL;DR fixes a stale 404 telemetry link and a smol fix regarding the missing `-p` alias for `supabase link --password` to match go cli/ ## ref: - closes supabase/supabase#46101
## What Moves the CI and release pipelines onto [Blacksmith](https://blacksmith.sh/) runners and threads Blacksmith's caching layers through the workflows that benefit from them. Runner moves: - PR-critical jobs in `test.yml` (`check`, `test-core`, `test-e2e`) → `blacksmith-8vcpu-ubuntu-2404`. - `cli-go-ci.yml::test` (Go unit/integration) → `blacksmith-8vcpu-ubuntu-2404`. - Release `build` (heavy multi-target Bun compile) → `blacksmith-32vcpu-ubuntu-2404`. - Release `smoke-test` matrix: Linux → `blacksmith-8vcpu-ubuntu-2404`, macOS → `blacksmith-6vcpu-macos-latest`, Windows → `blacksmith-8vcpu-windows-2025`. `macos-15-intel` stays on GitHub-hosted (Blacksmith macOS is ARM-only) and is skipped on prereleases so beta wall-clock isn't gated by the slowest leg — stable releases on `main` still run it. - Release `publish` / `publish-homebrew` / `publish-scoop` → `blacksmith-2vcpu-ubuntu-2404`. - Low-frequency Linux jobs (`cli-go-api-sync`, `cli-go-mirror`, `cli-go-codeql` non-Swift legs) → matching Blacksmith sizes for consistency. Caching: - `useblacksmith/checkout@v1` on `test-e2e` to exploit Blacksmith's sticky-disk git mirror with `fetch-depth: 0` (the cli-e2e shards need full history for `nx affected`). - Upstream `actions/cache@v5`, `actions/setup-node@v6`, `actions/setup-go@v6` — all SHA-pinned — for cache + toolchain setup. Initially this PR swapped to the `useblacksmith/cache`, `useblacksmith/setup-node`, `useblacksmith/setup-go` forks; partway through, those forks were [archived in favor of Blacksmith's runner-level interception](https://docs.blacksmith.sh/blacksmith-caching/dependencies-actions), which transparently routes upstream cache API calls to the same colocated backend. The final commit reverts to upstream and bumps the residual `actions/cache@v4` in `test.yml` to `@v5` so every cache step gets the new acceleration with continued upstream security patches. All third-party action pins use full commit SHAs with trailing `# v<N>` comments. ## Why The CI wall-clock on this repo had grown into the territory where it visibly slowed merges (test.yml routinely ~20+ min, release build ~30+ min). Blacksmith's larger runners + colocated cache cut both materially, and the `test-e2e` checkout in particular benefits from the sticky-disk git mirror because `fetch-depth: 0` was the dominant fixed cost in that job. The upstream-vs-fork pivot matters for hygiene: the archived `useblacksmith/*` cache forks still execute when SHA-pinned, but get no future security patches and miss out on Blacksmith's newer transparent acceleration. Going through upstream actions gives us both — Blacksmith routing *and* normal upstream maintenance — at no behavioral cost. ## Scope deliberately excluded - `cli-go-pg-prove.yml` / `cli-go-publish-migra.yml` Docker builds: separate follow-up, requires migrating to `useblacksmith/setup-docker-builder@v1` + `useblacksmith/build-push-action@v2` and dropping `cache-from: type=gha` (the GHA cache backend is *not* transparently routed by Blacksmith). Tracked, not in this PR. - Native arm64 smoke runner (replacing the QEMU emulation in the Linux smoke leg): planned follow-up. - Whether to delete `test.yml`'s explicit Go-binary cache step now that `$GOCACHE` is colocated: deferred until warm-cache rebuild time can be measured on Blacksmith. https://claude.ai/code/session_01KgHCbVTurxo4K9KivytQbt --------- Co-authored-by: Claude <noreply@anthropic.com>
This PR was automatically created to sync API types from the infrastructure repository. Changes were detected in the generated API code after syncing with the latest spec from infrastructure. Co-authored-by: supabase-cli-releaser[bot] <246109035+supabase-cli-releaser[bot]@users.noreply.github.com>
This PR was automatically created to sync API types from the infrastructure repository. Changes were detected in the generated API code after syncing with the latest spec from infrastructure. Co-authored-by: supabase-cli-releaser[bot] <246109035+supabase-cli-releaser[bot]@users.noreply.github.com>
Updates the help text for the `branches get` command in both the Go and TypeScript CLI implementations to clarify that password-dependent database fields are not populated for the main branch. **Changes:** - Updated `branchGetCmd` long description in `apps/cli-go/cmd/branches.go` to include a note explaining that `POSTGRES_URL` and `POSTGRES_URL_NON_POOLING` fields are not available for the main branch because production database credentials cannot be retrieved via API - Updated the command description in `apps/cli/src/legacy/commands/branches/get/get.command.ts` with the same clarification for consistency across CLI implementations This improves user experience by setting correct expectations when querying main branch details and reduces confusion about missing credential fields. Closes: CLI-1450 https://claude.ai/code/session_01Dq9V9d8nxzfFkqk3MaHBWB --------- Co-authored-by: Claude <noreply@anthropic.com>
## TL;DR fixes `db push --local` so prompts and status messages refer to the local database ( as requested by users, was confusing ) ## ref - closes #4971 Co-authored-by: Andrew Valleteau <avallete@users.noreply.github.com>
…#5258) Improves reliability of smoke tests on Linux by addressing race conditions and transient docker daemon failures during parallel test execution. **Changes:** - Enable containerd image store in docker daemon to support multi-platform manifest caching, allowing a single tag to hold both amd64 and arm64 images simultaneously - Add github actions caching for smoke-test base images (debian:bookworm-slim, amazonlinux:2023, alpine:3.21) across workflow runs to reduce first-time pull contention - Implement retry logic in smoke-test-linux.ts with exponential backoff for docker pull operations (up to 3 attempts) - Add retry handling for docker run exit code 125 (daemon/container-start errors) with one automatic retry before failing - Improve error reporting by capturing and logging both stdout and stderr separately, with better exit code visibility These changes address the root cause of intermittent "docker exit 125" failures that occur when eight parallel docker run calls race on first-time image pulls, which surfaces as container startup failures on a subset of jobs. https://claude.ai/code/session_01RsaTJoeDnJM45eLcqVNTar --------- Co-authored-by: Claude <noreply@anthropic.com>
…rix (#5311) Refactor the smoke test job to conditionally exclude the slowest runner (`macos-15-intel`) from the test matrix on prerelease builds, rather than using a job-level `if:` condition. **Changes:** - Moved the prerelease exclusion logic from a job-level `if:` condition into the strategy matrix itself using `fromJSON()` - The matrix now dynamically expands to either 3 runners (prerelease) or 4 runners (stable release) based on the `inputs.prerelease` flag - Updated comments to explain the rationale: `macos-15-intel` is the slowest leg and not available on Blacksmith, so excluding it from prerelease builds prevents it from blocking beta wall-clock time while stable releases still run the full matrix **Implementation details:** - Uses GitHub Actions' `fromJSON()` to conditionally build the matrix list, since the `matrix` context is not available in job-level `if:` conditions - The conditional expression selects between two hardcoded runner arrays based on the prerelease flag - This approach ensures the job runs with the correct matrix expansion rather than skipping the entire job conditionally https://claude.ai/code/session_01RDNmHeyREpf3ZBQLggK75q Co-authored-by: Claude <noreply@anthropic.com>
…5312) The release workflow's `publish` job was migrated to a Blacksmith runner in #5300, which broke npm publish: ``` npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/@supabase%2fcli-darwin-arm64 - Error verifying sigstore provenance bundle: Unsupported GitHub Actions runner environment: "self-hosted". Only "github-hosted" runners are supported when publishing with provenance. ``` `publish.ts` passes `--provenance` to `pnpm publish`, which has sigstore attest the build against the runner's OIDC identity. Blacksmith runners present as `self-hosted` to sigstore, so npm rejects the upload with E422. Move only the `publish` job back to `ubuntu-latest`. `build` and `smoke-test` stay on Blacksmith; `publish-homebrew` and `publish-scoop` don't go through npm/sigstore (they push to the tap/bucket repos via git) and also stay on Blacksmith. The publish job is short and not compute-bound, so the wall-clock cost of github-hosted is negligible. Failed run that motivated this: https://github.com/supabase/cli/actions/runs/26153946606 --- _Generated by [Claude Code](https://claude.ai/code/session_01RDNmHeyREpf3ZBQLggK75q)_ --------- Co-authored-by: Claude <noreply@anthropic.com>
## What changed Pass the npm release version into the bundled `supabase-go` binary via `-ldflags -X github.com/supabase/cli/internal/utils.Version=...` in `apps/cli/scripts/build.ts`. ## Why The legacy CLI shell forwards most commands to the bundled Go binary. That binary's upgrade banner reports the currently installed version from `utils.Version`, which is a string assigned at compile time via `-ldflags -X`. The Bun build script was only passing `-s -w`, so every release shipped a Go binary with `utils.Version=""`. The user-visible symptom was: ``` A new version of Supabase CLI is available: v2.100.1 (currently installed v) ``` `semver.Compare` treats the empty string as less than any valid version, so the upgrade prompt fired on every invocation regardless of the installed version. The `-X` injection had been part of the prior `.goreleaser.yml` build but was dropped during the goreleaser → Bun build-script migration. The bug only became user-visible once the `beta` and `stable` channels started building `shell=legacy` again, which is what bundles `supabase-go` into the release tarballs. ## Reviewer notes - The npm version (no leading `v`) is the right form to inject — `apps/cli-go/cmd/root.go:199` constructs `"v"+utils.Version` for the comparison and other callsites use the raw value. - The same migration also dropped `-X` injections for `utils.SentryDsn`, `utils.PostHogAPIKey`, and `utils.PostHogEndpoint`. The Go binary in current releases runs without Sentry/PostHog credentials. Out of scope for this PR — worth a separate ticket so the secret-handling and CI-secret wiring can be designed deliberately. Fixes #5308
The plan job in release.yml runs cycjimmy/semantic-release-action in dry-run mode purely to compute the next version, never reading new_release_notes, and softprops/action-gh-release in release-shared.yml gets no body. The result: GH Releases since the monorepo move publish with empty bodies (e.g. v2.100.1). A subsequent change will plumb release notes through the production publish path. This commit lands the prerequisites only: - apps/cli/package.json: add @semantic-release/release-notes-generator to release.plugins. It's a default semantic-release plugin bundled in cycjimmy/semantic-release-action's image, so no devDep is needed. Without this, new_release_notes would be empty even after wiring. - .github/workflows/backfill-release-notes.yml: workflow_dispatch with tag and apply inputs. Re-stages the repo on develop/main at the tag's commit (without the tag, so semantic-release computes it as the next release), asserts the computed version matches the tag, dumps the notes to the job summary, and only updates the GH Release body when apply=true. Lets us validate the changelog format end-to-end against an existing tag before touching the production publish path, and doubles as a fix-forward tool for releases that ship with an empty body (e.g. v2.100.1, the recent betas, or any future workflow_dispatch re-cut). ## What kind of change does this PR introduce? Bug fix, feature, docs update, ... ## What is the current behavior? Please link any relevant issues here. ## What is the new behavior? Feel free to include screenshots if it includes visual changes. ## Additional context Add any other context or screenshots. Co-authored-by: Claude <noreply@anthropic.com>
…5314) ## What changed - `apps/cli/scripts/build.ts` — `buildGoTarget` now reads `SENTRY_DSN`, `POSTHOG_API_KEY`, and `POSTHOG_ENDPOINT` from `process.env` and appends a matching `-X github.com/supabase/cli/internal/utils.{SentryDsn,PostHogAPIKey,PostHogEndpoint}=...` segment to the Go linker flags when the value is set. - `.github/workflows/release-shared.yml` — the `build` job's `env:` block now exposes the three repo secrets so release builds get the values populated. ## Why Companion fix to #5313. The legacy CLI shell forwards telemetry through the bundled `supabase-go` binary, which reads its Sentry DSN and PostHog credentials from `-ldflags -X`-injected vars. The bun build script only injected `utils.Version`, so every release after the goreleaser → bun-script migration shipped with empty credentials: - `apps/cli-go/internal/telemetry/service.go:61` constructs the PostHog client with an empty key and host → the client returns a no-op (`internal/telemetry/client.go:32-56`). - `apps/cli-go/cmd/root.go:78` initializes Sentry with an empty DSN → no-op client. PostHog event flow stopped on 2026-05-18 with v2.98.2 (the last build produced by the prior pipeline). Restoring these injections matches the historical `.goreleaser.yml` behavior using the same three repo secrets, which already exist (`gh secret list --repo supabase/cli`). ## Reviewer notes - The TS shells don't need build-time injection. The `next` shell carries hardcoded PostHog defaults with runtime env overrides (`apps/cli/src/next/config/cli-config.layer.ts`), and `legacy` delegates everything to the Go binary via `LegacyGoProxy`. - The env vars are conditionally appended in the build script, so local builds and PR smoke builds (which don't expose the secrets) produce binaries with empty telemetry credentials and the existing safe no-op runtime behavior — no leakage and no test breakage. - Verified locally: `SENTRY_DSN=… POSTHOG_API_KEY=… POSTHOG_ENDPOINT=… pnpm exec bun apps/cli/scripts/build.ts --version 2.100.1 --shell legacy` produces a `supabase-go` whose `strings` output contains the three sentinel values; running the same command with the envs unset produces a binary with none of them. Fixes CLI-1506 Co-authored-by: Julien Goux <hi@jgoux.dev>
Fixes the backfill-release-notes workflow so it actually produces the right notes for an arbitrary historical tag, and moves the engine out of inline bash into a reusable bun script. ## Why the original workflow couldn't produce correct notes Backfilling an old tag isn't symmetric with running semantic-release on a normal push — it trips on five separate things at once, each of which silently sends it down a wrong path: - **Branch detection.** `cycjimmy/semantic-release-action` reads the branch via `env-ci` (`$GITHUB_REF` / `$GITHUB_REF_NAME`), not `git rev-parse --abbrev-ref HEAD`. Dispatching the workflow from any branch other than `develop`/`main` left semantic-release looking at an unconfigured branch and silently emitting no `new_release_*` outputs. - **"Behind remote" check.** semantic-release runs `git ls-remote <repositoryUrl> <branch>` and exits silently if the remote tip differs from local HEAD — which is always true when re-staging at an old tag. - **Channel notes for historical tags.** semantic-release reads `git log --notes=refs/notes/semantic-release*`. `actions/checkout` doesn't fetch `refs/notes/*` by default, and some historical tags (e.g. `v2.99.0-beta.1`) have no channel annotation at all — leaving them as `channels=[null]`, which the prerelease filter drops. semantic-release then walks past them and `lastRelease` drifts back far enough to drag unrelated commits into the changelog. - **Drift in `release.branches` config.** Before commit `2515885` (May 11) the `develop` branch had no explicit `"channel": "beta"`, so semantic-release defaulted the channel to the branch name; before #5316 the plugin chain didn't include `release-notes-generator`. A historical checkout therefore produces empty or misclassified notes. - **Output format.** Parsing `cycjimmy/semantic-release-action`'s stdout returns marked-terminal rendered ANSI/whitespace, not raw markdown — so even when the right notes were computed, the GH release body would render wrong. ## What this PR does Moves the workflow's logic into `apps/cli/scripts/backfill-release-notes.ts` and calls `semantic-release` *programmatically* so it can return `nextRelease.notes` as raw markdown directly. The script's setup works around each of the issues above in a temp clone (so the original workspace stays clean): 1. Clones the repo to a temp directory and fetches `refs/notes/*` from both the source repo and origin. 2. Synthesises a `develop`/`main` branch at the tag's commit and seeds the other configured branch from `refs/remotes/origin/<other>`. 3. Backfills missing channel notes on every reachable tag (`v*-beta.*` → `beta`, `v*-alpha.*` → `alpha`, else `latest`). 4. Patches the temp clone's `apps/cli/package.json` with the *current* `release` config so historical checkouts use today's `channel: "beta"` and plugin chain. 5. Uses `git config --local url.<local>.insteadOf <github>` so semantic-release's `ls-remote` silently targets the local clone (satisfying the "behind remote" check) while `repositoryUrl` stays the real GitHub URL — keeping commit/PR links correct in the rendered notes. 6. Calls `semanticRelease({ dryRun: true, noCi: true, repositoryUrl }, { cwd: ... })` and prints `nextRelease.notes` to stdout, or with `--apply` calls `gh release edit --notes-file`. The workflow itself reduces to: checkout, setup, `bun apps/cli/scripts/backfill-release-notes.ts --tag $TAG`, mirror to the job summary, then conditionally re-run with `--apply`. ## Sample output (`v2.99.0-beta.2`) ```sh $ bun apps/cli/scripts/backfill-release-notes.ts --tag v2.99.0-beta.2 ``` ```markdown # [2.99.0-beta.2](v2.99.0-beta.1...v2.99.0-beta.2) (2026-05-20) ### Bug Fixes * **ci:** make release re-cut reliable after stale-bytes runs ([#5209](#5209)) ([ef1b13a](ef1b13a)), closes [#5205](#5205) [#5207](#5207) [#5205](#5205) [#5207](#5207) [#App](https://github.com/supabase/cli/issues/App) * **cli:** make npm publish idempotent for partial-failure re-runs ([#5207](#5207)) ([bbeaec7](bbeaec7)), closes [#release-creation](https://github.com/supabase/cli/issues/release-creation) * **cli:** mark platform binaries executable in pnpm publish tarball ([#5201](#5201)) ([b2b397a](b2b397a)), closes [#5199](#5199) * **cli:** smoke test now actually verifies our local build ([#5205](#5205)) ([9109056](9109056)), closes [#5199](#5199) [#5200](#5200) ``` Exactly the 5 commits between `v2.99.0-beta.1` and `v2.99.0-beta.2`, with GitHub links rendered against `https://github.com/supabase/cli` regardless of the local-clone redirection. ## Related The same `release.repositoryUrl` / `ls-remote` interaction and channel-notes drift will need to be addressed on the production publish path (`.github/workflows/release-shared.yml`) once Stage B of the changelog plumbing (`claude/wire-release-notes-publish`) lands. --------- Co-authored-by: Claude <noreply@anthropic.com>
…the right baseline (#5321) Fixes `bun apps/cli/scripts/backfill-release-notes.ts --tag v2.100.0-beta.2`, which currently errors with `semantic-release did not compute a next release for v2.100.0-beta.2`. ## Why it fails today semantic-release's `lastRelease` picker accepts both prerelease tags on the branch's channel **and** stable tags via the prerelease filter's stable-fallback clause, then sorts the survivors by semver. When a stable and a beta share a commit (e.g. `v2.100.0` and `v2.100.0-beta.2` are both at `9a22aff6`), the stable wins the sort — and since it points at HEAD itself, semantic-release reports "Found 0 commits since last release" and emits no `nextRelease`. The script's version-mismatch guard then exits with the "did not compute a next release" error. ## Fix After resolving the target tag's commit, delete *every* local tag that points at that commit, not just the target. Co-located tags are by definition the same release, and dropping them lets semantic-release fall back to the genuine prior release on the channel (`v2.100.0-beta.1` in the example). ## Sample output (`v2.100.0-beta.2`) ```sh $ bun apps/cli/scripts/backfill-release-notes.ts --tag v2.100.0-beta.2 ``` ```markdown # [2.100.0-beta.2](v2.100.0-beta.1...v2.100.0-beta.2) (2026-05-20) ### Features * **cli:** add hidden flag support for legacy commands ([#5278](#5278)) ([9a22aff](9a22aff)), closes [#5277](#5277) ``` Regression-checked locally that `v2.99.0-beta.2` (where stable and beta are on different commits) and `v2.100.1` (stable backfill) still produce the same output as before. --- _Generated by [Claude Code](https://claude.ai/code/session_016p4TNXziTipWocxmgLDc8b)_ Co-authored-by: Claude <noreply@anthropic.com>
## What kind of change does this PR introduce? Simplify the action, let the ts script leverage the logic.
Fixes a silent failure in the `backfill-release-notes` script where `git notes add` would fail in CI environments that lack a configured git committer identity and GPG signing setup. **Changes:** - Configure local git user email and name in the temporary clone before seeding channel notes - Disable `commit.gpgsign` and `tag.gpgsign` in the clone to prevent failures when global signing config is inherited but no signing key is available - Remove `.nothrow()` from the `git notes add` call since the git config is now properly set up and failures should be surfaced This ensures that semantic-release can correctly identify prior beta tags and compute the correct next version during the backfill process. https://claude.ai/code/session_01FX5hRgt2dXeZzMoLGcyU9A Co-authored-by: Claude <claude@anthropic.com>
Add a new GitHub Actions workflow to smoke test the `supabase/setup-cli` action against published CLI versions. This catches regressions like setup-cli#427 where musl libc and archive layout changes broke the action on Alpine silently. **Key changes:** - New `.github/workflows/setup-cli-smoke-test.yml` workflow that: - Tests CLI installation across Ubuntu, macOS, and Windows runners - Includes a dedicated Alpine container job to catch musl libc regressions - Verifies the installed CLI version matches the expected version - Can be triggered manually via `workflow_dispatch` or called from other workflows - Updated `.github/workflows/release-shared.yml` to: - Add a `setup-cli-smoke` job that runs after beta releases - Runs as a post-publish signal without gating other release jobs - Uses `always() && needs.publish.result == 'success'` to run even when homebrew/scoop jobs are skipped or fail The Alpine job is kept separate because GitHub Actions only honors the `container:` field on Linux runners, and the musl-vs-glibc regressions only reproduce inside a real Alpine container. Closes: CLI-1507 https://claude.ai/code/session_01NzzeYET8sYhpCVdSvBBJhC --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Julien Goux <hi@jgoux.dev>
The smoke test workflow compares the output of `supabase --version`
against the `VERSION` environment variable. However, `supabase
--version` outputs the version without a leading `v`, while release tags
and setup-cli inputs include it. This causes version mismatches during
testing.
**Changes:**
- Strip the leading `v` from `VERSION` before comparison in both smoke
test jobs
- Add clarifying comments explaining why the stripping is necessary
The fix uses bash parameter expansion (`${VERSION#v}`) to remove the
leading `v` if present, ensuring the comparison is between two
consistently formatted version strings.
https://claude.ai/code/session_01S5jBFMNp5mHAWhS9inCagB
Co-authored-by: Claude <noreply@anthropic.com>
…5324) Fix the backfill-release-notes script to correctly detect the git branch when running semantic-release in dry-run mode. The script was passing the full process environment to semantic-release, which includes GitHub Actions detection variables (GITHUB_REF, GITHUB_ACTIONS, etc.). The semantic-release library uses env-ci to detect the current branch, and env-ci prioritizes these CI environment variables over the actual git HEAD state. This caused env-ci to report the wrong branch when backfilling from a workflow that ran on a different branch than the current clone's HEAD, leading to semantic-release errors about local branches being behind remote. **Key changes:** - Create a filtered child environment that strips GitHub Actions detection variables (GITHUB_ACTIONS, GITHUB_REF, GITHUB_REF_NAME, GITHUB_HEAD_REF, GITHUB_BASE_REF, GITHUB_EVENT_NAME, CI) - Pass the filtered environment to semantic-release instead of the full process environment - This allows env-ci to fall back to reading the branch from git HEAD in the clone, which is the correct source of truth for the backfill operation https://claude.ai/code/session_01QQsjHNdZTJHhLWr2FYSjhe Co-authored-by: Claude <noreply@anthropic.com>
Stage A (#prior PR) added @semantic-release/release-notes-generator to the plugin chain and a manual backfill workflow to validate the format. This change wires the same notes into the production release pipeline so future releases on develop/main come with a populated GH Release body instead of an empty page. - release.yml: capture new_release_notes from the plan job's cycjimmy/semantic-release-action step into a release_notes job output using a heredoc with a random delimiter. SR_NOTES is passed via env and emitted with printf (not echo) so attacker-influenced commit bodies / PR titles can't be interpolated as shell. The workflow_dispatch re-cut path skips semantic-release entirely, so release_notes is the empty string in that case - the operator can follow up with the backfill-release-notes workflow to populate the body afterwards. - release-shared.yml: new optional release_notes workflow_call input, wired as the body of the softprops/action-gh-release step that creates the draft release. No generate_release_notes: true - the action appends GitHub's auto notes to any supplied body, which would duplicate content. ## What kind of change does this PR introduce? Bug fix, feature, docs update, ... ## What is the current behavior? Please link any relevant issues here. ## What is the new behavior? Feel free to include screenshots if it includes visual changes. ## Additional context Add any other context or screenshots. --------- Co-authored-by: Claude <noreply@anthropic.com>
…#5220) ## Summary This change introduces a new flag called `no-apply` to the `db schema declarative sync command` , allowing users to generate migration files without applying them to the local database. ## Current behavior ``` $ supabase db schema declarative sync --name test ... Created new migration at supabase/migrations/20260428093833_test.sql Apply this migration to local database? [Y/n] ``` The only escape hatches today: - `--apply` — force-applies the migration (opposite of what's wanted) - Closing stdin via piping, e.g. `true | supabase db schema declarative sync ... 2>&1 | cat` Closes #5218 ## New behavior - If `--no-apply` is set, the command writes the migration file and skips the apply step without any prompt - `--no-apply` overrides global `--yes` and cannot be combined with `--apply`. - Parity with legacy TS is maintained --------- Co-authored-by: Andrew Valleteau <avallete@users.noreply.github.com>
restores go cli parity for `supabase domains create` by requiring `--custom-hostname` in the ts legacy shim instead of only failing later in go
Coverage Report for CI Build 26213641541Warning No base build found for commit Coverage: 63.767%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsRequires a base build to compare against. How to fix this → Coverage Stats
💛 - Coveralls |
avallete
approved these changes
May 21, 2026
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
5 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.
vfrom VERSION before comparing (chore(ci): strip leadingvfrom VERSION before comparing #5326)