chore: production deploy - #6514
Open
supabase-cli-releaser[bot] wants to merge 12 commits into
Open
Conversation
) ## What kind of change does this PR introduce? Tooling/chore — adds commitlint, tied to a fixed scope list. ## What is the current behavior? There is no commitlint or commitizen setup. PR titles must follow conventional-commits format (checked in CI by `amannn/action-semantic-pull-request`), but scopes are unrestricted free text, enforced only by human review. ## What is the new behavior? - Adds `commitlint.config.js` with a `scope-enum` rule: one scope per real turbo/pnpm workspace project (`api`, `cli`, `cli-e2e`, `cli-go`, `cli-test-helpers`, `config`, `docs`, `process-compose`, `stack` — verified against `pnpm -r list`) plus escape scopes for changes that don't map to a single project (`ci`, `repo`, `misc`, `release`). The 8 per-platform `packages/cli-{platform}` binary-wrapper packages are folded into `cli`. `release` isn't a turbo project (`tools/release` has no `package.json`) but is kept as an escape scope because `propose-release-notes.ts` genuinely commits with that scope. - Adds a local `commit-msg` git hook via husky that runs commitlint on every commit. CI checkouts skip installing this hook (`HUSKY=0` in the shared setup action) so bot-authored commits are never gated by it — scope enforcement for those stays on the PR-title CI check. - Mirrors the same scope list into the `amannn/action-semantic-pull-request` step in `lint-pull-request.yml`, so PR titles are held to the same list in CI. - Updates `.github/dependabot.yml`: the `npm` and `docker` ecosystems previously auto-generated scopes (`deps`/`deps-dev`/`docker`) that aren't in the new fixed list, which would have started failing their own PR-title check — both remapped to `misc`. The `gomod` ecosystem had no `commit-message` config at all, so it fell back to a repository-detected scope also outside the allowlist — mapped to `chore(cli-go): ` since that's precisely the project those updates belong to. `github-actions` (already `ci`) is untouched. - Documents the local commit-msg hook in `CONTRIBUTING.md`, and adds one clarifying sentence to `AGENTS.md` pointing at `commitlint.config.js` as the source of truth for allowed scopes. No commitizen/interactive prompt added — commitlint validates whatever message is typed.
…2285) (#6497) ## Summary An explicit `--workdir`/`SUPABASE_WORKDIR` could silently let `loadCliConfig`/`findCliProjectRoot` climb ancestor directories to find `supabase/config.{toml,json}` — so `--workdir ./sub` where `sub/supabase/` doesn't exist could silently load, or **push**, an unrelated parent project's config instead of failing. A defaulted (unset) workdir still climbs exactly as before. Linear: [CLI-2285](https://linear.app/supabase/issue/CLI-2285/explicit-workdir-must-not-climb-to-a-parent-project-config-diffpush). ## What changed - `LegacyCliSettings` gains `explicitWorkdir: boolean`; a new `legacyShouldSearchAncestors(cliSettings)` helper (`command-internal/legacy-workdir-search.ts`) gates the ancestor search at every affected call site: `config diff/push/pull`, `gen types`, `seed buckets`, `storage ls/mv/rm/cp`, `functions new`, `experimental workers`, and `functions serve/deploy`. - `packages/config`'s `findCliProjectRoot` gains an optional `FindCliProjectPathsOptions` parameter (additive), matching `findCliProjectPaths`'s existing `search: false` support. - `config diff/push/pull`, `gen types`, `storage`, and `seed buckets` now hard-fail with a clear error instead of silently falling back to embedded defaults (or an unrelated ancestor's config) when an explicit workdir has no project. - The same commands now validate the workdir is an existing directory up front (reusing the existing `start`/`stop`/`status` pattern), so a typo'd path fails with "no such directory" instead of a confusing "file not found". - The missing-project message (`command-internal/legacy-workdir-project.ts`) no longer suggests `supabase init` for an explicit workdir — which could scaffold a fresh config at the wrong path, leading to a subsequent `push` overwriting the real project — and instead names the resolved path, suggesting an ancestor's path when one genuinely has a project. - `gen types` no longer leaks a raw `CliConfigParseError` tag as its error message on a malformed config. - `experimental workers new` gained the same workdir-existence guard `functions new` already had, closing an identical scaffold-at-a-nonexistent-path gap. ## Follow-ups filed separately (explicitly out of scope here) - `secrets set` ignores `--workdir` entirely (loads from `runtimeInfo.cwd`). - Extending the explicit-workdir hard-fail policy to the `db`/`migration` TOML-only loaders. - `--debug` workdir logging, `--workdir` help-text tightening, and a couple of smaller consistency nits (error-code unification across the `config` family, `workers push`'s hardcoded error paths).
….4 in /apps/cli-go in the go-minor group across 1 directory (#6504) Bumps the go-minor group with 1 update in the /apps/cli-go directory: [github.com/posthog/posthog-go](https://github.com/posthog/posthog-go). Updates `github.com/posthog/posthog-go` from 1.24.3 to 1.24.4 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/posthog/posthog-go/releases">github.com/posthog/posthog-go's releases</a>.</em></p> <blockquote> <h2>1.24.4</h2> <h2>Unreleased</h2> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/PostHog/posthog-go/blob/main/CHANGELOG.md">github.com/posthog/posthog-go's changelog</a>.</em></p> <blockquote> <h2>1.24.4</h2> <h3>Patch Changes</h3> <ul> <li>c3270b6: Align local feature flag property matching with the flags service, including boolean-array precedence, canonical JSON stringification, and operator-specific case folding.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/PostHog/posthog-go/commit/0216c2384b67ef39914e20fd0065c57243fb42d2"><code>0216c23</code></a> chore: release v1.24.4 [version bump] [skip ci]</li> <li><a href="https://github.com/PostHog/posthog-go/commit/c3270b6bd8138865c0f0d0a57affaceb7a2bb6cb"><code>c3270b6</code></a> fix(flags): align local exact matching with the flags service (<a href="https://redirect.github.com/posthog/posthog-go/issues/300">#300</a>)</li> <li><a href="https://github.com/PostHog/posthog-go/commit/d5152ea6c4155c781cbdc0512eb99b60977fe90e"><code>d5152ea</code></a> chore(deps): bump the github-actions group with 2 updates (<a href="https://redirect.github.com/posthog/posthog-go/issues/304">#304</a>)</li> <li><a href="https://github.com/PostHog/posthog-go/commit/518931f315c1ff5bb2786d4b53b0c9fc316a1d1b"><code>518931f</code></a> chore(deps-dev): bump <code>@changesets/cli</code> from 3.0.0 to 3.0.1 in the release-tool...</li> <li>See full diff in <a href="https://github.com/posthog/posthog-go/compare/v1.24.3...v1.24.4">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…sumer (CLI-2339) (#6498) ## Summary CLI-2320 confined `auth.email.template.*.content_path`/`auth.email.notification.*.content_path` resolution to the project root, but only inside `config push`'s own content loader. This centralizes that containment into the shared resolver `legacyResolveEmailTemplateContentPath` (`legacy-config-validate.ts`), so it now protects every consumer, with no flag and no opt-out: `config push`, `start` (an eager pre-Docker validation pass covering every configured template plus every enabled notification — the same set Kong's mount builder consumes), and the shared config-validation path reached by `db`/`migration`/`status`/`stop`/`functions deploy`/`functions serve`/`functions download`/`gen types`/`inspect`/`bootstrap`. Linear: CLI-2339 (follow-up from CLI-2320's own PR review, #6489). While extending the check's reach, two bugs surfaced and are fixed in the same change: - The canonicalization helper treated any `realpath` failure as "this path doesn't exist yet" and fell back to lexical resolution — which also covers a dangling symlink, an `EACCES`-blocked target, or a symlink loop, all of which exist on disk but couldn't be canonicalized. That let an in-root symlink pointing outside the project root bypass containment silently, most seriously for `start`'s Kong mount (a root-privileged, `rw` Docker bind mount). Fixed by distinguishing "genuinely absent" from "exists but uncanonicalizable" and following a symlink to its real target before checking it. The ancestor walk was also rewritten iteratively to remove a stack-depth limit on deeply nested missing paths. - `start`'s Kong mount resolved and validated a path early, then independently re-derived and used a second, unresolved path much later when building the Docker bind mount — a check/use gap and duplicated resolution logic. The validated, read-verified path is now threaded straight through to the bind-mount builder instead of being re-derived. The rejection message now includes the declared `content_path` value and the project root (not the fully symlink-dereferenced target, to avoid echoing back where an escaping symlink actually points). ## What changed - `legacy-config-validate.ts` — `legacyResolveEmailTemplateContentPath` now canonicalizes and containment-checks its result before returning; new `canonicalPathForContainment`/ `canonicalizeExistingPath`/`isPathContainedInRoot` helpers. - `push.auth-email-content.ts` — deleted its local, now-redundant containment helpers; both template and notification loading route through the shared resolver. - `start.handler.ts`/`kong.service.ts` — `resolveKongEmailTemplateMounts` resolves, containment- checks, and read-verifies every Kong-mounted template/notification once, early, before any Docker work; `LegacyKongEmailTemplateMount` carries the resolved path, and `legacyBuildKongEmailTemplateBind` is now a pure formatter with no resolution logic of its own. - `SIDE_EFFECTS.md` updates across `start`, `status`, `stop`, `db diff`, `migration squash`, `functions deploy/serve/download`, and one line in `apps/cli/AGENTS.md`'s "config validation has one home" section. Follow-ups filed for the adjacent untrusted-path fields this ticket didn't touch (CLI-2344), and a message-polish gap where an `EACCES` behind a followed symlink surfaces a raw filesystem error instead of the usual containment message (CLI-2345) — in both cases the path is still rejected, just with a less specific error.
## TL;DR Adds live e2e coverage for `branches get`, `branches update` and `branches disable` ## whats introduced? - `branches get`: creates a branch, fetches it by name and asserts the pretty connection table renders - `branches update`: creates a branch, renames it with `--name --output json`, asserts the confirmation and payload, then proves the new name resolves through `branches get` - `branches disable`: creates and deletes a branch so branching is enabled with no preview branches left, disables preview branching for the project and asserts the confirmation on stdout ## ref: - closes: CLI-2327 - passed here: https://github.com/supabase/cli/actions/runs/34112181467
## TL;DR fixes `supabase sso update --log-level error <id>` failing with `accepts 1 arg(s), received 2` by registering the built-in `--log-level` as value taking in the raw argv scanners.. ## whats biting the user? `--log-level` shows up in every command's help and the parser accepts it, but the raw argv scanners did not know it consumes a value so `error` was counted as an extra positional and the command refused to run. A typed `--log-level` also killed shell completion for the rest of the line. ## now fixed by: - registering `log-level` in `PERSISTENT_VALUE_FLAG_NAMES` and `globalFlagsWithValues`, so positional counting consumes its value like every other global - registering the built-in flags where output format and shell completion resolve, so `--version` output and tab completion keep working around them also added regression tests for the issue's exact spelling plus the pre-path, inline, completion, and version spellings ## ref: - closes CLI-2329 - closes #6482
## Summary Rewrites `@supabase/stack` around one managed-only runtime shared by strict native and container execution modes. The package owns durable configuration and secrets, sticky ports, artifact preparation, lifecycle arbitration, per-service eager or lazy activation, service migrations, ingress, retained and live logs, and exact resource cleanup. A stopped stack has no resident supervisor or runtime resources: status and retained logs come from durable state, while a later start creates a fresh owner and performs clean recovery. PostgreSQL 17 is the only eager service by default; other enabled services activate through stack ingress, and callers can configure eager activation. Dependency-ready workloads start concurrently. Docker-compatible engines, including Podman, share the same container path. Enabled lazy services prepare their artifacts in the background after startup by default. `preparation: "on-demand"` retains full lazy downloading, while explicit `prepare()` remains available in either mode. Foreground activation prepares its dependency closure concurrently and shares in-flight downloads with background preparation. All selected workload downloads can run concurrently. Native archives are streamed to disk while hashing, verified before extraction, and decompressed without retaining whole archives in memory. Runtime cleanup cancels unfinished transfers and retains completed cache entries. Status exposes artifact preparation separately from service readiness, and explicit preparation reports progress through `onProgress`. Edge Functions are served through the stack-owned Edge Runtime for package consumers. The package runs independently of the CLI and accepts normalized `StackConfig` values without reading `config.toml`. All CLI integration, including `supabase functions serve` and lifecycle commands under `experimental start`, belongs to M5 in separate PRs. Existing CLI Functions behavior is preserved. The deleted `next` CLI was a disposable proving ground and is not part of this PR. Service preparation now lives in the published runtime artifacts: PostgreSQL owns first boot and bundled migrations, service helpers own migration and Pooler tenant provisioning, and Node services expose public launchers shared with their images. The stack supplies instance settings and sequences those commands. Default images use the configured slim-services tags or digests, including the artifacts from [slim-services #299](supabase/slim-services#299) and the BEAM versions republished after [slim-services #302](supabase/slim-services#302). Native downloads are checked against the checksum published with the same release. BEAM launchers own the shared runtime defaults in native and container modes; Vector configuration and Edge Functions bootstrap remain stack-owned. Unix control sockets bind inside owner-private directories. Container mount paths preserve CSV special characters, and default state paths use the user home directory when `HOME` is absent. Obsolete process-compose integration and superseded runtime helpers are removed. Supersedes #6385
) ## TL;DR adds live e2e coverage for `network-restrictions get` and `update`, covering the command family ## whats introduced? - `network-restrictions get`: reads the target project's restrictions and proves the json payload carries `entitlement`, `config` and `status` - `network-restrictions update`: captures the current allowlist, replaces it with documentation ranges, proves the replacement in its own output and through get, then restore s... ## ref: - closes: CLI-2288 - tested here: https://github.com/supabase/cli/actions/runs/33969368307
Bumps the actions-major group with 2 updates: [docker/setup-qemu-action](https://github.com/docker/setup-qemu-action) and [linear/linear-release-action](https://github.com/linear/linear-release-action). Updates `docker/setup-qemu-action` from 4.2.0 to 4.3.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/docker/setup-qemu-action/releases">docker/setup-qemu-action's releases</a>.</em></p> <blockquote> <h2>v4.3.0</h2> <ul> <li>Bump <code>@docker/actions-toolkit</code> from 0.92.0 to 0.96.0 in <a href="https://redirect.github.com/docker/setup-qemu-action/pull/336">docker/setup-qemu-action#336</a></li> <li>Bump <code>@sigstore/verify</code> from 3.1.0 to 3.1.1 in <a href="https://redirect.github.com/docker/setup-qemu-action/pull/316">docker/setup-qemu-action#316</a></li> <li>Bump brace-expansion from 1.1.15 to 1.1.18 in <a href="https://redirect.github.com/docker/setup-qemu-action/pull/332">docker/setup-qemu-action#332</a></li> <li>Bump js-yaml from 4.2.0 to 4.3.1 in <a href="https://redirect.github.com/docker/setup-qemu-action/pull/334">docker/setup-qemu-action#334</a></li> <li>Bump postcss from 8.5.10 to 8.5.25 in <a href="https://redirect.github.com/docker/setup-qemu-action/pull/331">docker/setup-qemu-action#331</a></li> <li>Bump sigstore from 4.1.0 to 4.1.1 in <a href="https://redirect.github.com/docker/setup-qemu-action/pull/317">docker/setup-qemu-action#317</a></li> <li>Bump undici from 6.27.0 to 6.28.0 in <a href="https://redirect.github.com/docker/setup-qemu-action/pull/333">docker/setup-qemu-action#333</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/docker/setup-qemu-action/compare/v4.2.0...v4.3.0">https://github.com/docker/setup-qemu-action/compare/v4.2.0...v4.3.0</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/docker/setup-qemu-action/commit/1f40c72289eff860ee54a304f1438e3cff362e0a"><code>1f40c72</code></a> Merge pull request <a href="https://redirect.github.com/docker/setup-qemu-action/issues/336">#336</a> from docker/dependabot/npm_and_yarn/docker/actions-to...</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/932216e29e2417c3aa0bc5aec3c57089030cef2c"><code>932216e</code></a> [dependabot skip] chore: update generated content</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/a39e895360e601ae54e9ac97b8ea3b99e5f40491"><code>a39e895</code></a> build(deps): bump <code>@docker/actions-toolkit</code> from 0.92.0 to 0.96.0</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/a98ae9ffe777adf16ca44873bab9926427b262fa"><code>a98ae9f</code></a> Merge pull request <a href="https://redirect.github.com/docker/setup-qemu-action/issues/333">#333</a> from docker/dependabot/npm_and_yarn/undici-6.28.0</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/8ebc9d118344dda0af3e25d2a7330010dd33e951"><code>8ebc9d1</code></a> [dependabot skip] chore: update generated content</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/c41e3fcbc0d6742101e0310c3b008ac3b16a9529"><code>c41e3fc</code></a> build(deps): bump undici from 6.27.0 to 6.28.0</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/5fc60dfac60f723a3386e73530ff8067f2848f60"><code>5fc60df</code></a> Merge pull request <a href="https://redirect.github.com/docker/setup-qemu-action/issues/332">#332</a> from docker/dependabot/npm_and_yarn/brace-expansion-1...</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/a26e892bb646b50218299a9b391e7a4b0322d96a"><code>a26e892</code></a> Merge pull request <a href="https://redirect.github.com/docker/setup-qemu-action/issues/328">#328</a> from docker/dependabot/github_actions/actions/checkou...</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/aa6d04232374700651c6e7be400e859600041423"><code>aa6d042</code></a> Merge pull request <a href="https://redirect.github.com/docker/setup-qemu-action/issues/324">#324</a> from docker/dependabot/github_actions/actions/setup-n...</li> <li><a href="https://github.com/docker/setup-qemu-action/commit/d381ce5c16de15c000da8929fd1fc6e8fdef19e1"><code>d381ce5</code></a> Merge pull request <a href="https://redirect.github.com/docker/setup-qemu-action/issues/317">#317</a> from docker/dependabot/npm_and_yarn/sigstore-4.1.1</li> <li>Additional commits viewable in <a href="https://github.com/docker/setup-qemu-action/compare/96fe6ef7f33517b61c61be40b68a1882f3264fb8...1f40c72289eff860ee54a304f1438e3cff362e0a">compare view</a></li> </ul> </details> <br /> Updates `linear/linear-release-action` from 0.17.1 to 0.17.2 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/linear/linear-release-action/releases">linear/linear-release-action's releases</a>.</em></p> <blockquote> <h2>v0.17.2</h2> <h2>What's Changed</h2> <ul> <li>Release v0.17.2 by <a href="https://github.com/axelniklasson"><code>@axelniklasson</code></a> in <a href="https://redirect.github.com/linear/linear-release-action/pull/67">linear/linear-release-action#67</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/linear/linear-release-action/compare/v0.17.1...v0.17.2">https://github.com/linear/linear-release-action/compare/v0.17.1...v0.17.2</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/linear/linear-release-action/commit/53ad0f863963e7f8e270fba18426bbb55ef55384"><code>53ad0f8</code></a> Release v0.17.2 (<a href="https://redirect.github.com/linear/linear-release-action/issues/67">#67</a>)</li> <li>See full diff in <a href="https://github.com/linear/linear-release-action/compare/3f31fcf14c110cc53579fcc3575a26d469c413b4...53ad0f863963e7f8e270fba18426bbb55ef55384">compare view</a></li> </ul> </details> <br /> Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| res.setHeader("x-seen-forwarded-host", req.headers["x-forwarded-host"] ?? ""); | ||
| res.setHeader("x-seen-forwarded-proto", req.headers["x-forwarded-proto"] ?? ""); | ||
| res.setHeader("x-seen-forwarded-for", req.headers["x-forwarded-for"] ?? ""); | ||
| res.end(`${req.method}:${req.url}`); |
…stat throws (CLI-2345) (#6518) ## What kind of change does this PR introduce? Bug fix. ## What is the current behavior? `canonicalizeExistingPath` in `apps/cli/src/command-internal/legacy-config-validate.ts` follows an in-root symlink one hop by hand (via `readlinkSync`) when `realpathSync` fails, so a `content_path` containment check can catch a dangling/looping/unsearchable-target symlink escaping the project root. When the symlink's target sits one hop inside a directory that's unsearchable (`EACCES`, e.g. `chmod 000`), the fallback `lstatSync(path, { throwIfNoEntry: false })` call itself throws — `throwIfNoEntry: false` only suppresses `ENOENT`, not `EACCES` — and that throw was unguarded, escaping as a raw filesystem `Error` instead of the polished `LegacyConfigValidateError` ("resolves outside the project root") every other containment-rejection case produces. Not a security regression — the path was still rejected in every tested environment — it was a message-polish gap. Code review while fixing this surfaced the identical bug in `legacyIsExistingFile` (the `"notification"` email-content section's twin resolution path, via `statSync`), which had the same unguarded `throwIfNoEntry: false` gap. Fixes CLI-2345. ## What is the new behavior? - `canonicalizeExistingPath`'s `lstatSync` fallback is now guarded: any non-`ENOENT` throw there returns the path as-is (same fallback already used for a non-symlink entry or too-deep symlink chain), so the caller's containment check still runs and rejects normally. - `legacyIsExistingFile` is guarded the same way: an unstattable dirent is treated as present, so the declared path keeps winning over the legacy `supabase/`-relative fallback and the real cause surfaces instead of a raw fs error or a silent retarget. - Updated the `canonicalizeExistingPath` JSDoc to accurately describe what this guard does and doesn't guarantee (the lexical comparison isn't fully fail-closed on its own; every caller's own read of the resolved file's bytes is the actual backstop). - Tightened the existing EACCES regression test to assert the specific error/message, parametrized the three symlink-containment tests across both `template`/`notification` sections, and added a permission-free `ENAMETOOLONG` regression test so this code path stays covered in environments where `chmod 000` isn't enforced (root, some containers, Windows).
…he slim-services feed (#6521) ## Summary Dependabot's docker updates on `apps/cli-go/pkg/config/templates/Dockerfile` have been landing red — see #6502 (realtime) and #6503 (postgres). Two independent causes, plus the automation the second one leaves behind. **1. A unit test asserted the exact current pins while reading them from the live manifest.** `slim-images.unit.test.ts` had a `maps current docker.io pins onto the published slim tags` case that fed `dockerfileServiceImageRaw(alias)` in and asserted a spelled-out version for `pg`, `supavisor`, `realtime`, and `storage`. Any bump of those four failed the unit suite by construction. The assertions that must track the manifest — which slim repository each alias maps to — already live in the `it.each` above and slice the tag off before comparing, so they stay. Live-tag validation also survives more strongly elsewhere: `start.slim-images.e2e.test.ts` translates the current manifest pins and actually pulls them, so an unpublished translated tag fails CI on the registry rather than on a hand-typed string. The version-bearing block only encoded the per-service tag-prefix scheme, so it is replaced with fixed pins covering the same scheme, plus the uppercase-`V` normalization arm in `slimTagForService` that had no coverage. **2. `sync-stack-service-versions.yml` targeted files that no longer exist.** It ran `pnpm sync:versions` in `packages/stack` and committed `packages/stack/src/ServiceCatalog.ts`. #6440 deleted both the script and that file, so the workflow would have hard-failed on the next dependabot Dockerfile PR. It survived #6502/#6503 only because those were opened about two hours before #6440 merged. **3. The stack's pins now ride the feed that can actually maintain them.** Deleting that workflow leaves `WorkloadCatalog.ts` — `ServiceCatalog.ts`'s replacement — with no automation, so this adds it. The catalog pins each workload to an exact slim-services artifact release: a version **plus its `ghcr.io/supabase/cli` image digest**, per ADR 0017, which makes the artifact release the boundary for service startup defaults. Dependabot owns the Dockerfile and structurally cannot own this table — it resolves registry tags and never produces a `sha256:` digest, which is why repointing the old workflow was not an option. slim-services already sends this repo a `mirror-slim-image` `repository_dispatch` per release carrying `service`/`version`/`digest`, to drive the ECR mirror. `sync-stack-workload-catalog.yml` subscribes to that same dispatch and opens a PR pinning the release. It is deliberately a separate workflow from `mirror-slim-image.yml`: that mirror runs against the sender's 15-minute verification poll, and a catalog PR must never delay it or turn its run red. ## Reviewer notes Only two source values change per release. `artifactFor` derives `releaseTag`, `assetName`, and every download URL from `service` + `version`, and `releases` is derived from `defaultVersion` plus the container image, so rewriting the `native(...)` positional version and image is the whole change. **postgres is the one service carrying two supported release lines** (17.x and 15.x via `additionalReleases`), so the plan picks its target by release line — a 15.x release moves the additional entry and can never overwrite the 17.x default. That is the main correctness risk here and it has a dedicated test. A release on a line the catalog does not carry, a service it does not model, and a re-dispatch of an already-pinned release are all successful no-ops, so the sender's retry path does not open duplicate PRs. The dispatch payload arrives with whatever authority holds the dispatch token, so `sync-workload-catalog.ts` revalidates `service`/`version`/`digest` against the same patterns `mirror-slim-image.yml` uses rather than trusting the workflow. Those patterns are what stop a version or digest breaking out of the TypeScript string literals it writes into. `planCatalogUpdate` is pure and covered by 21 `bun:test` cases in `.github/scripts/`, which `github-scripts-ci.yml` already tests and type-checks. One of them sweeps every service the real catalog models, so a newly modelled workload is covered without editing a fixture list. `WorkloadCatalog.ts` also gains a provenance comment: it and the Dockerfile list overlapping service versions and are meant to diverge, so the next reader needs to know not to "reconcile" them. ## Linked issue No Linear ticket — repository maintenance prompted by the two failing dependabot PRs above. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01PWXmTVTiQCwuyjZ8Mfw9NL --------- Co-authored-by: Claude <noreply@anthropic.com>
…#6519) ## Summary The `Codegen` check fetched the live staging spec on every pull request and diffed the result against the committed `pkg/api`. That conflated two questions: whether the pull request left generated code inconsistent, and whether staging had drifted ahead of the repository. The second dominated, so a spec change turned every open pull request touching `apps/cli-go` red at once — none of which the authors caused or could fix — and it made all of those runs depend on staging being reachable. This pins the spec instead: - `apps/cli-go/api/v1-openapi.yaml` is a committed snapshot of the staging spec, and `go generate` reads it instead of `https://api.supabase.green/api/v1-yaml`. The per-PR `Codegen` check is now hermetic: it fails only when `pkg/api` no longer matches the snapshot it was generated from, and it reproduces offline. - The API Sync workflow becomes the sole reader of the live spec. It refreshes the snapshot and regenerates the client together in one pull request, so upstream drift produces that one pull request instead of a failure on every open one. Its diff now shows the upstream API change rather than only generated Go. - Its change detection covers the snapshot as well as `pkg/api`, so an upstream edit that codegen ignores (a description, an example) is committed rather than refetched and discarded on every run. - `api/README.md` is rewritten. It still documented the pre-URL `beta.yaml` flow, and its links to the generated files were broken relative paths. This restores the model `packages/api` already uses, where `pnpm generate` runs only in the sync workflow and per-PR drift is checked against the committed `openapi.json`. ## Drift the snapshot exposed Seeding the snapshot was expected to regenerate `pkg/api` byte-identically. It did not: staging had drifted ahead of the committed client, which is exactly the accumulation the old check could never land. Two changes came in, and they are worth a look: - `StorageConfigResponseOutput.MigrationVersion` is now `nullable.Nullable[string]`. Assigning it to the `string` field `storage.TargetMigration` no longer compiles, so `FromRemoteStorageConfig` unwraps it with the same `Get()` guard `FromRemoteAuthConfig` already uses. Behavior change worth noting: when the platform omits the field, the local value is left untouched rather than overwritten with `""`, consistent with the surrounding intent that unset config should not change platform defaults. - Several `UpdateCustomHostnameResponseOutput` result fields became optional pointers. Nothing outside `pkg/api` consumes that type, so no call sites needed changes. ## Generated-file marking Committing a 468 KB spec snapshot raised the question of generated-file marking, and `.gitattributes` carried no `linguist-*` entries at all, so the repository's roughly 3.5 MB of generated output was skewing GitHub's language statistics and expanding in diffs. All of it is now marked `linguist-generated`: the Go client and spec snapshot, `packages/api/src/generated/`, the docs config schemas, and the lockfiles. `turbo.json`'s `generate` outputs and the `go generate` directives are the source of truth for that list, so only generated files are marked. Hand-written codegen inputs (`pkg/api/*.cfg.yaml`, `api/overlay.yaml`) are untouched, as are large but authored files such as the integration test suites. The attribute is GitHub-only — git, CI, and local diffs behave identically, and the files are collapsed behind a click rather than hidden, so the sync PR's spec diff and lockfile changes remain reviewable. ## Linked issue N/A — CI reliability change, no linked issue. ## Checklist - [x] The PR title follows [Conventional Commits](https://www.conventionalcommits.org/). ## Reviewer notes One open decision: the snapshot's file name. `v1-openapi.yaml` matches the `/api/v1-yaml` endpoint; `beta.yaml` was the name before codegen moved to the live URL, if continuity is preferred. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01TKDPB9bwSx5WM7juDAM7CT --------- Co-authored-by: Claude <noreply@anthropic.com>
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.
branchesget, update and disable (CLI-2327) (test(cli): coverbranchesget, update and disable (CLI-2327) #6492)--log-levelvalue (CLI-2329) (fix(cli): consume--log-levelvalue (CLI-2329) #6483)network-restrictionsget and update (CLI-2288) (test(cli): covernetwork-restrictionsget and update (CLI-2288) #6478)