CI/CD Pipelines & Testing Infrastructure

Relevant source files

• .github/workflows/all-good.yaml
• .github/workflows/auto-update.yaml
• .github/workflows/check-prisma-migrations.yaml
• .github/workflows/db-migration-backwards-compatibility.yaml
• .github/workflows/e2e-api-tests-local-emulator.yaml
• .github/workflows/e2e-api-tests.yaml
• .github/workflows/e2e-custom-base-port-api-tests.yaml
• .github/workflows/lint-and-build.yaml
• .github/workflows/setup-tests-with-custom-base-port.yaml
• .github/workflows/setup-tests.yaml
• .github/workflows/table-of-contents.yaml
• apps/backend/prisma/migrations/20260201230004_env_to_branch_config/migration.sql
• apps/backend/scripts/bulldozer-payments-init.ts
• apps/backend/scripts/run-bulldozer-studio.ts
• apps/backend/scripts/verify-data-integrity/api.ts
• apps/backend/scripts/verify-data-integrity/clickhouse-sync-verifier.ts
• apps/backend/scripts/verify-data-integrity/index.ts
• apps/backend/scripts/verify-data-integrity/recurse.ts
• apps/backend/scripts/verify-data-integrity/stripe-payout-integrity.ts
• apps/backend/src/app/api/latest/internal/payments/transactions/route.tsx
• apps/backend/src/lib/bulldozer/db/tables/compact-table.ts
• apps/backend/src/lib/bulldozer/db/tables/concat-table.ts
• apps/e2e/.env
• apps/e2e/.env.development
• apps/e2e/tests/backend/performance/metrics.test.ts
• apps/e2e/tests/general/setup-wizard.test.ts
• apps/e2e/tests/helpers.ts
• apps/e2e/tests/snapshot-serializer.ts
• apps/e2e/vitest.config.ts
• docs/.gitignore
• pnpm-workspace.yaml
• scripts/generate-sdks.ts
• scripts/utils.ts

This page documents the automated workflows and testing frameworks used to maintain the reliability, security, and data integrity of Stack Auth. The infrastructure is primarily built on GitHub Actions and Vitest, covering everything from unit tests and linting to full end-to-end (E2E) API testing and database migration compatibility.

Workflow Orchestration

The CI/CD pipeline is designed to provide rapid feedback while ensuring that no regressions are introduced to the core authentication logic or the multi-tenant database schema.

Core Pipelines Overview

Workflow	Purpose	Trigger
lint-and-build.yaml	Validates code style, types, and buildability.	Push (main/dev), PR
e2e-api-tests.yaml	Runs full suite of API tests against a live environment.	Push (main/dev), PR
check-prisma-migrations.yaml	Ensures the Prisma schema matches generated migrations.	Push (main/dev), PR
db-migration-backwards-compatibility.yaml	Verifies new migrations don't break existing code.	Push (non-main), PR
setup-tests.yaml	Validates the CLI initialization and setup wizard.	Push (main/dev), PR
all-good.yaml	Aggregate status check for branch protection.	Push (main/dev), PR

The "All Good" Status Check

The all-good.yaml workflow acts as a gatekeeper. It polls the GitHub Checks API to ensure all other mandatory workflows have completed successfully before a PR can be merged .github/workflows/all-good.yaml15-51 It specifically ignores non-blocking checks like claude-review .github/workflows/all-good.yaml45 It implements a polling loop that waits for completion and fails if any required check has a non-success conclusion .github/workflows/all-good.yaml53-112

Sources: .github/workflows/all-good.yaml1-113

---

E2E API Testing Infrastructure

The E2E suite is the most critical part of the testing infrastructure. It spins up the entire Stack Auth stack, including dependencies like PostgreSQL, ClickHouse, and Svix.

Test Environment Setup

The environment is configured via .env.test.local files, which are cloned from development templates during the CI run .github/workflows/e2e-api-tests.yaml57-96

1. Docker Dependencies: A background action starts docker compose for external services .github/workflows/e2e-api-tests.yaml44-52
2. Service Initialization: The backend, dashboard, mock OAuth server, and background workers (email queue, cron jobs) are started sequentially using JarvusInnovations/background-action .github/workflows/e2e-api-tests.yaml119-163
3. Wait Strategy: The pipeline uses pnpm exec wait-on to ensure TCP/HTTP ports (e.g., 8128 for Postgres, 8136 for ClickHouse) are ready before proceeding .github/workflows/e2e-api-tests.yaml101-115

Custom Port Prefix Testing

To ensure the system is robust against port conflicts and environment variations, a dedicated workflow e2e-custom-base-port-api-tests.yaml runs the entire suite using a custom NEXT_PUBLIC_STACK_PORT_PREFIX (e.g., "67") .github/workflows/e2e-custom-base-port-api-tests.yaml21 This shifts all service ports (e.g., Postgres moves from 8128 to 6728, Svix to 6713) .github/workflows/e2e-custom-base-port-api-tests.yaml20-107

E2E Test Flow Diagram

This diagram maps the CI workflow steps to the actual service entities started in the background.

Sources: .github/workflows/e2e-api-tests.yaml44-180 .github/workflows/e2e-custom-base-port-api-tests.yaml112-156

---

Snapshot Serialization & Sanitization

Because the E2E tests generate dynamic data (UUIDs, timestamps, API keys), the snapshot-serializer.ts is used to sanitize Vitest snapshots. This ensures that snapshots remain deterministic across test runs.

Key Sanitization Logic

• API Keys: Identifies keys using isApiKey and replaces them with a generic string indicating the key type (e.g., stack_sk_<stripped secret server API key>) apps/e2e/tests/snapshot-serializer.ts156-159
• UUIDs: Replaces all standard UUID patterns with <stripped UUID> apps/e2e/tests/snapshot-serializer.ts162-168
• Time/Ports: Replaces local machine port prefixes and elapsed time strings with placeholders like <$NEXT_PUBLIC_STACK_PORT_PREFIX> apps/e2e/tests/snapshot-serializer.ts123-125
• Sensitive Headers: Strips headers like set-cookie, authorization, and x-stack-request-id apps/e2e/tests/snapshot-serializer.ts8-32
• JSON Fields: Automatically strips fields containing dynamic values such as access_token, refresh_token, exp, and various _at_millis timestamps apps/e2e/tests/snapshot-serializer.ts36-88

Sources: apps/e2e/tests/snapshot-serializer.ts1-126

---

Database Integrity & Compatibility

Stack Auth implements strict checks for database schema changes to prevent data corruption and ensure zero-downtime deployments.

Prisma Migration Checks

The check-prisma-migrations.yaml workflow runs prisma migrate diff to compare the current state of the database against the local schema.prisma file .github/workflows/check-prisma-migrations.yaml60-61 If the schema has been modified without a corresponding migration file being generated, the check fails.

Backwards Compatibility Testing

The db-migration-backwards-compatibility.yaml workflow performs a "drift test":

1. It identifies if migrations have changed between the current branch and the base branch (dev or main) .github/workflows/db-migration-backwards-compatibility.yaml26-49
2. It applies the new migrations from the current branch to a fresh database .github/workflows/db-migration-backwards-compatibility.yaml68-71 .github/workflows/db-migration-backwards-compatibility.yaml160
3. It then runs the old code (from the base branch) against this newly migrated database .github/workflows/db-migration-backwards-compatibility.yaml74-85
4. This ensures that the database changes are additive and do not break existing production logic.

Data Integrity Script

After tests complete, the verify-data-integrity.ts script is executed .github/workflows/e2e-api-tests.yaml179-180 It performs deep checks:

• ClickHouse Sync: Validates that events in Postgres have been correctly mirrored to ClickHouse via verifyClickhouseSync apps/backend/scripts/verify-data-integrity/index.ts16
• Payments: Verifies integrity across all billing tables using createPaymentsSchema and createBulldozerExecutionContext apps/backend/scripts/verify-data-integrity/index.ts174-176
• Stripe: Checks Stripe payout consistency via verifyStripePayoutIntegrity (unless using mock keys) apps/backend/scripts/verify-data-integrity/index.ts19 apps/backend/scripts/verify-data-integrity/index.ts159-161

Sources: .github/workflows/db-migration-backwards-compatibility.yaml1-200 apps/backend/scripts/verify-data-integrity/index.ts1-180 .github/workflows/check-prisma-migrations.yaml1-62

---

Setup Wizard & CLI Testing

The setup-tests.yaml workflow specifically validates the CLI initialization and the initial onboarding experience.

Implementation Detail

• It builds the internal packages first using pnpm run build:packages .github/workflows/setup-tests.yaml38
• It executes pnpm run codegen to ensure all generated types are up to date .github/workflows/setup-tests.yaml39
• It runs pnpm run dev to start the local development environment .github/workflows/setup-tests.yaml44
• It executes tests that simulate a user running the setup wizard (e.g., setup-wizard.test.ts), ensuring that project initialization works correctly .github/workflows/setup-tests.yaml50-59

CLI Testing Entity Mapping

Sources: .github/workflows/setup-tests.yaml1-59 .github/workflows/e2e-api-tests.yaml24 apps/backend/scripts/verify-data-integrity/index.ts21