Files
supabase/e2e/studio
e66d8eb094 chore(deps): bump Supabase CLI to ^2.114.0 (speculative: Selfhosted Studio E2E Start supabase flake) (#49198)
<!-- ccr-slack-attribution -->
_Requested by **Ivan Vasilov** · [Slack
thread](https://supabase.slack.com/archives/C063LNYJJKS/p1787058646458219?thread_ts=1787058646.458219&cid=C063LNYJJKS)_

**Before:** the root `package.json` pins the Supabase CLI at `supabase:
^2.76.10`, and `pnpm-lock.yaml` resolves it to `2.76.14`.

**After:** it pins `supabase: ^2.114.0`.

This bumps the Supabase CLI that `pnpm run e2e:setup:cli` and `pnpm run
setup:cli` shell out to, so local dev and the E2E workflows boot the
local stack with a CLI from this month instead of one from ~38 minor
releases ago.

**How:** a one-line version change to the `supabase` devDependency in
the root `package.json`. Nothing else in the repo changes — no workflow,
config, or test changes.

### ⚠️ This PR is incomplete: `pnpm-lock.yaml` still needs regenerating

`pnpm-lock.yaml` is **not** updated in this PR, so `pnpm install
--frozen-lockfile` will fail until someone runs:

```bash
pnpm install --lockfile-only
```

and pushes the result to this branch. The lockfile could not be
regenerated in the environment this PR was authored in: pnpm re-resolves
`apps/studio`'s `"@std/path": "npm:@jsr/std__path@^1.0.8"` on every
install, and `npm.jsr.io` is not reachable from there
(`ERR_PNPM_FETCH_403`). Treat this PR as needing one extra commit before
it can go green.

### Why `^2.114.0` and not `^2.115.0`

`2.115.0` is the current `latest` on npm, but it was published only
hours ago, and `pnpm-workspace.yaml` sets `minimumReleaseAge: 4320` (3
days) with `supabase` not in `minimumReleaseAgeExclude`. Pinning
`2.115.0` today would fail the repo's own supply-chain check. `2.114.0`
(2026-08-12) is the newest release that satisfies that policy.

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Dependency bump. **Speculative** — this is an experiment, not a
confirmed fix.

## What is the current behavior?

The `Selfhosted Studio E2E Tests` workflow has been failing on `master`
at the `Start supabase` step. Recent runs:

- https://github.com/supabase/supabase/actions/runs/32092940311
- https://github.com/supabase/supabase/actions/runs/32131961447

In the Slack thread, Ivan Vasilov suggested trying a newer CLI and
Alaister Young endorsed giving it a go.

## What is the new behavior?

The workflow runs `supabase start` with CLI 2.114.0 instead of 2.76.14.

The question this PR is trying to answer is simply **"does a newer CLI
help this flake?"** It is not a diagnosis and not a claimed fix. If CI
still fails at `Start supabase` on this branch, the bump can be kept or
dropped on its own merits and the investigation continues elsewhere.

## Additional context

**Verification status:** none locally. The bump was not exercised
locally — this repo checkout has no `node_modules` (see the lockfile
note above), so `pnpm typecheck`, `pnpm lint`, and `pnpm test:studio`
were not run, and neither was `supabase start`. CI on this PR is the
only signal.

**Call-site compatibility check.** CLI 2.99/2.100 moved to a new
TypeScript shell with a stricter argument parser: command-specific flags
must now come *after* the subcommand. Both call sites in the root
`package.json` already use that order, so no script changes are needed:

```
supabase stop --all --no-backup --workdir ./e2e/studio
supabase start --exclude studio,mailpit --workdir ./e2e/studio
```

**Changelog entries between 2.76.14 and 2.114.0 that touch `supabase
start` or local config.** Listed so reviewers know what changed in the
range — **not** as a claim about what is failing in CI:

- **2.112.0** — `supabase start` no longer hangs when analytics
migrations fail; the analytics container exits and retries instead of
booting against an unmigrated database
([#6093](https://github.com/supabase/cli/pull/6093)).
- **2.112.0** — `supabase start` reuses existing volumes instead of
failing when they already exist
([#6037](https://github.com/supabase/cli/pull/6037)); Kong reloads after
`supabase db reset`
([#6017](https://github.com/supabase/cli/pull/6017)); custom auth email
templates survive `db reset`
([#6065](https://github.com/supabase/cli/pull/6065)); `supabase start`
works on SELinux-enforcing hosts
([#6000](https://github.com/supabase/cli/pull/6000)).
- **2.106.0 — behavior change worth watching.**
`[api].auto_expose_new_tables` now resolves to `false` when unset, and
local start/reset revokes default Data API privileges for newly created
`public` tables, sequences, and functions
([#5524](https://github.com/supabase/cli/pull/5524)). Neither
`supabase/config.toml` nor `e2e/studio/supabase/config.toml` sets this
key, so this default applies. If E2E specs create `public` objects and
then read them through the Data API, they may need explicit `GRANT`s
(the deprecated escape hatch is `auto_expose_new_tables = true`).
- **2.106.0** — when the CLI detects a coding-agent environment, or
`--agent yes` is passed, commands default to JSON output
([#5532](https://github.com/supabase/cli/pull/5532)). `e2e:setup:cli`
already passes `--output json` to `supabase status` explicitly, so this
should be a no-op here.
- **2.100.0** — stricter flag ordering, covered above.
- **2.112.0** — `functions deploy` no longer forwards `NPM_AUTH_TOKEN`
into Docker bundling
([#6005](https://github.com/supabase/cli/pull/6005)). Not used by these
workflows.
- **2.107.0** — pg-delta is the default schema diff engine for `db diff`
/ `db pull` on new projects
([#5511](https://github.com/supabase/cli/pull/5511)).
- Many bundled Docker image bumps across the range (`supabase/postgres`
17.6.1.087 → later patches, `postgres-meta`, `vector` 0.28.1 → 0.53.0,
Studio image), plus `fix(analytics): wait for logflare before starting
vector` (2.84.3) and `fix: use correct docker.sock binding with vector`
(2.84.7).

Full comparison:
https://github.com/supabase/cli/compare/v2.76.14...v2.114.0


---
_Generated by [Claude
Code](https://claude.ai/code/session_0143DrDMGnSSwuHebTPJv7ZY)_

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
2026-08-19 10:52:25 +02:00
..

Supabase Studio E2E Tests

Set up

Prerequisites

For Self-Hosted Tests

  • Nothing is required, running with IS_PLATFORM=false should run the tests locally with a self hosted docker container

For Platform Tests

  1. Create a platform account - You can authenticate using either:
    • Email and password
    • GitHub OAuth (requires TOTP 2FA)
  2. Create an organization on the platform, this can be done if run locally through mise fullstack
  3. Generate a Personal Access Token (PAT) for API access
  4. Configure the environment variables below (see Authentication section for details on email vs GitHub auth)

Configure Environment

Choose the appropriate example file based on your testing scenario:

For self-hosted tests:

cp .env.local.self-hosted.example .env.local

For platform tests with email authentication:

cp .env.local.email.example .env.local

For platform tests with GitHub authentication:

cp .env.local.github.example .env.local

Edit .env.local and set the appropriate values based on your test environment (see Environment Variables section below).

Install the playwright browser

⚠️ This should be done in the e2e/studio directory

cd e2e/studio

pnpm exec playwright install

Environment Variables

Configure your tests by setting the following environment variables in .env.local. We have examples of what required on self hosted and platform:

Core Configuration

  • STUDIO_URL: The URL where Studio is running (default: http://localhost:8082)
  • API_URL: The Supabase API endpoint (default: https://localhost:8080)
  • IS_PLATFORM: Set to true for platform tests, false for self-hosted (default: false)
    • When true: Tests run serially (1 worker) due to API rate limits
    • When false: Tests run in parallel (5 workers)

Authentication (Required for Platform Tests)

⚠️ Before running platform tests, you must create an account and organization on the platform you're testing.

Authentication is automatically enabled when either email/password OR GitHub credentials are configured.

Email Authentication
  • EMAIL: Your platform account email
  • PASSWORD: Your platform account password
  • PROJECT_REF: Project reference (optional, will be auto-created if not provided)

When both EMAIL and PASSWORD are set, the tests will authenticate using email/password. HCaptcha is mocked during test setup. Note this only works on local and staging environments

GitHub Authentication
  • GITHUB_USER: Your GitHub username
  • GITHUB_PASS: Your GitHub password
  • GITHUB_TOTP: Your GitHub TOTP secret for 2FA (required, as GitHub enforces 2FA)

When GITHUB_USER, GITHUB_PASS, and GITHUB_TOTP are all set, the tests will authenticate using GitHub OAuth with TOTP-based 2FA. The authentication flow handles:

  • Clicking "Sign In with GitHub" button
  • Filling GitHub credentials
  • Generating and submitting TOTP codes
  • Handling GitHub authorization prompts
  • Automatic retry on failure (up to 3 attempts)

Getting your GitHub TOTP secret: When setting up 2FA on GitHub, you'll see a QR code. Click "enter this text code instead" to reveal the secret key. This is the value to use for GITHUB_TOTP.

Platform-Specific Variables (Required when IS_PLATFORM=true)

  • ORG_SLUG: Organization slug (default: default)
  • SUPA_REGION: Supabase region (default: us-east-1)
  • SUPA_PAT: Personal Access Token for API authentication (default: test)
  • BRANCH_NAME: Name for the test branch/project (default: e2e-test-local)

Optional Variables

  • OPENAI_API_KEY: Required for the AI Assistant test (assistant.spec.ts). Without this variable, the assistant test will be skipped.
  • VERCEL_AUTOMATION_BYPASS_SELFHOSTED_STUDIO: Bypass token for Vercel protection (default: false)

Setup Commands Based on Configuration

The test setup automatically runs different commands based on your environment:

  • Platform + Localhost (IS_PLATFORM=true and STUDIO_URL=localhost): Runs pnpm run e2e:setup:platform
  • Platform + Remote (IS_PLATFORM=true and remote STUDIO_URL): No web server setup
  • Self-hosted (IS_PLATFORM=false): Runs pnpm run e2e:setup:selfhosted

Running the tests

Check the package.json for the available commands and environments.

pnpm run e2e

With Playwright UI:

pnpm run e2e -- --ui

Tips for development

  • Read Playwright Best Practices
  • Use pnpm run e2e -- --ui to get the playwright UI.
  • Add the tests in examples/examples.ts to Cursor as context.
  • Add messages to expect statements to make them easier to debug.

Example:

await expect(page.getByRole('heading', { name: 'Logs', exact: true }), {
  message: 'Logs heading should be visible',
}).toBeVisible()
  • Use the test utility instead of playwrights test.
import { test } from '../utils/test'
  • Use the PWDEBUG environment variable to debug the tests.
PWDEBUG=1 pnpm run e2e -- --ui

What should I test?

  • Can the feature be navigated to?
  • Does the feature load correctly?
  • Can you do the actions (filtering, sorting, opening dialogs, etc)?

API Mocks

Read here: https://playwright.dev/docs/mock#mock-api-requests

Example:

await page.route(`*/**/logs.all*`, async (route) => {
  await route.fulfill({ body: JSON.stringify(mockAPILogs) })
})