integration-prisma-next.yml

name: Integration — prisma-next (EQL v3)

# Real ZeroKMS ciphertext against a real Postgres, on BOTH database variants —
# the prisma-next leg of the shared test-kit family driver (the same catalog,
# oracle, and single-vs-bulk crossover as the Drizzle and Supabase jobs).
#
# The prisma-next adapter talks straight to the database, so it does not need
# PostgREST — but it does need to work on managed Postgres, where the `postgres`
# role is not a superuser, the EQL install takes its self-skipping path, and the
# ORE domains cannot hold data. The Supabase compose file brings up PostgREST
# too; this job simply ignores it.
#
# Separate from `tests.yml` on purpose: these suites need CipherStash credentials
# and a database, and they THROW rather than skip when unconfigured. Keeping them
# out of the unit job is what lets `pnpm test` stay runnable with neither.

on:
  push:
    branches: [main]
    paths:
      - 'packages/stack/src/eql/v3/**'
      - 'packages/prisma-next/**'
      # Source layers the adapter's encoding/round-trip rests on: a break here
      # (not just under src/eql/v3) can produce wrong rows, so trigger the live
      # suite that would catch it.
      - 'packages/stack/src/encryption/**'
      - 'packages/stack/src/schema/**'
      - 'packages/schema/**'
      - 'packages/test-kit/**'
      - 'packages/cli/src/installer/**'
      - 'local/docker-compose.postgres.yml'
      - 'local/docker-compose.supabase.yml'
      - 'local/supabase-init.sql'
      - '.github/workflows/integration-prisma-next.yml'
      - '.github/actions/integration-setup/**'
      - '.github/actions/integration-db/**'
  pull_request:
    branches: ['**']
    # Repeated verbatim: GitHub Actions does not support YAML anchors/aliases.
    paths:
      - 'packages/stack/src/eql/v3/**'
      - 'packages/prisma-next/**'
      # Source layers the adapter's encoding/round-trip rests on: a break here
      # (not just under src/eql/v3) can produce wrong rows, so trigger the live
      # suite that would catch it.
      - 'packages/stack/src/encryption/**'
      - 'packages/stack/src/schema/**'
      - 'packages/schema/**'
      - 'packages/test-kit/**'
      - 'packages/cli/src/installer/**'
      - 'local/docker-compose.postgres.yml'
      - 'local/docker-compose.supabase.yml'
      - 'local/supabase-init.sql'
      - '.github/workflows/integration-prisma-next.yml'
      - '.github/actions/integration-setup/**'
      - '.github/actions/integration-db/**'

jobs:
  integration:
    name: prisma-next v3 integration (db=${{ matrix.db }})
    runs-on: blacksmith-4vcpu-ubuntu-2404
    # No concurrency group: `integration-db` gives each job its own compose
    # project and ephemeral host ports, so live-DB jobs no longer contend and do
    # not need serialising. See that action for why the old
    # `integration-live-db-<db>` group had to go (it cancelled a third
    # contender rather than queueing it).
    #
    # Fork PRs have no secrets. Skip cleanly rather than fail on something the
    # contributor cannot fix — `tests.yml` still gives them a green signal.
    if: ${{ github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository }}

    strategy:
      fail-fast: false
      # prisma-next talks straight to Postgres, so it runs against BOTH
      # databases. The Supabase variant is not a formality: its `postgres` role
      # is not a superuser, so the EQL install takes its self-skipping path. A
      # suite that passes on a superuser database can still fail there.
      matrix:
        db: [postgres, supabase]

    env:
      CS_WORKSPACE_CRN: ${{ vars.CS_WORKSPACE_CRN }}
      CS_CLIENT_ID: ${{ vars.CS_CLIENT_ID }}
      CS_CLIENT_KEY: ${{ secrets.CS_CLIENT_KEY }}
      CS_CLIENT_ACCESS_KEY: ${{ secrets.CS_CLIENT_ACCESS_KEY }}
      # EXPLICIT, never inferred — same rationale as the Drizzle workflow.
      CS_IT_DB_VARIANT: ${{ matrix.db }}

    steps:
      - uses: actions/checkout@v6
      - uses: ./.github/actions/integration-setup

      # Fast pre-flight: fail in seconds if a secret was rotated or cleared,
      # before the docker pull. The in-test `requireIntegrationEnv` is the
      # correctness guarantee; this is the cheap one.
      - name: Require CipherStash secrets
        uses: ./.github/actions/require-cs-secrets
        with:
          workspace-crn: ${{ vars.CS_WORKSPACE_CRN }}
          client-id: ${{ vars.CS_CLIENT_ID }}
          client-key: ${{ secrets.CS_CLIENT_KEY }}
          client-access-key: ${{ secrets.CS_CLIENT_ACCESS_KEY }}

      # No pre-`up` cleanup step any more: the project name is unique per job, so
      # a container leaked by a hard-killed prior run cannot hold this job's
      # name or its (ephemeral) port. Blanket-pruning would now be actively
      # unsafe — without the concurrency group, another job's stack may be live
      # on this runner.
      - name: Start ${{ matrix.db }}
        id: db
        uses: ./.github/actions/integration-db
        with:
          db: ${{ matrix.db }}

      # `globalSetup` installs EQL v3 by shelling out to the real
      # `stash eql install --eql-version 3`, so an installer regression fails
      # here rather than hiding behind a test-only SQL apply.
      - name: prisma-next v3 family suites
        run: pnpm --filter @cipherstash/prisma-next run test:integration
        env:
          # Step env, not a `.env` file: `dotenv/config` does not override an
          # already-set `process.env`, so these win and no secret hits disk.
          DATABASE_URL: ${{ steps.db.outputs.database-url }}
          PGRST_URL: ${{ steps.db.outputs.pgrest-url }}

      # Guarded on the project being set: if the stack never came up, there is
      # nothing to tear down and an unguarded `-p ""` would fail the job with a
      # confusing error that masks the real one.
      - name: Stop ${{ matrix.db }}
        if: always() && env.CS_COMPOSE_PROJECT != ''
        run: docker compose -p "$CS_COMPOSE_PROJECT" -f "$CS_COMPOSE_FILE" down -v