CI for Prisma Tests with GitHub Actions (Prisma 7)

To run Prisma ORM tests automatically, you define a GitHub Actions workflow that installs your dependencies, generates Prisma Client, provides a database, and runs your test suites on every pull request. This article builds that workflow step by step, with jobs for unit, integration, and end-to-end tests. This is part 5 of a five-part series on testing with Prisma ORM.

Updated (July 2026): This article was rewritten for Prisma ORM 7 and current GitHub Actions. Action versions were verified against GitHub on 2026-07-09: actions/checkout@v7, actions/setup-node@v6, and pnpm/action-setup@v6 are current major versions. The workflow YAML shown here was validated with a YAML parser (js-yaml). Two things changed from the original 2023 article: the integration database now uses a GitHub Actions Postgres service container instead of a downloaded Docker Compose binary, and the build step runs npx prisma generate because on Prisma 7 the client is generated into your project rather than shipped ready-to-use. The test commands themselves are the ones verified in parts 1 through 4 of this series.

Introduction

Over the last four articles you mocked Prisma Client, wrote unit tests, wrote integration tests, and wrote end-to-end tests. There is one rough edge left: you run those tests manually.

In this article you automate them so that changes are tested as pull requests are opened against your main branch.

What are continuous integration pipelines?

A continuous integration (CI) pipeline is a set of steps that run before a change is merged. You have likely seen the acronym CI/CD, covering continuous integration and continuous deployment. This article focuses on CI: building, testing, and merging your code.

Many tools can run pipelines: Jenkins, CircleCI, GitLab CI, AWS CodePipeline, and more. This article uses GitHub Actions, which runs your pipeline against code changes whenever you open a pull request.

Technologies you will use

Node.js 20 or later
GitHub Actions
Postgres as a CI service container
Prisma ORM 7
pnpm

Assumed knowledge

Basic knowledge of Git and GitHub
The unit, integration, and end-to-end tests from parts 1 through 4

Set up a workflow

GitHub Actions reads workflow files from a .github/workflows folder in your repository. Create one:

mkdir -p .github/workflows
touch .github/workflows/tests.yml

Give the workflow a name and configure it to run on pull requests against main. Define the environment variables your app needs at the workflow level so every job can use them:

# .github/workflows/tests.yml
name: Tests
on:
  pull_request:
    branches:
      - main
env:
  DATABASE_URL: postgres://postgres:postgres@localhost:5432/quotes
  VITE_API_URL: http://localhost:3000
  API_SECRET: secretvalue

Note: Indentation matters in YAML. Improper indentation will cause the file to fail to parse.

A reusable build action

Every test job needs the same preparation: install pnpm and Node.js, install dependencies, and generate Prisma Client. On Prisma 7 the client is generated into your project, not shipped inside @prisma/client, so npx prisma generate must run before any code that imports the client.

Put these shared steps in a composite action. Create .github/actions/build/action.yml:

# .github/actions/build/action.yml
name: 'Build'
description: 'Sets up the repository and installs dependencies'
runs:
  using: 'composite'
  steps:
    - name: Set up pnpm
      uses: pnpm/action-setup@v6
      with:
        version: latest
    - name: Install Node.js
      uses: actions/setup-node@v6
      with:
        node-version: 22
        cache: pnpm
    - name: Install dependencies
      shell: bash
      run: pnpm install
    - name: Generate Prisma Client
      shell: bash
      run: npx prisma generate

This action sets up pnpm and Node.js 22, installs node_modules, and generates Prisma Client.

Add a unit testing job

Each job runs its steps in an isolated environment. Add a jobs section with a unit-tests job that checks out the repo, runs the build action, and runs the unit tests:

# .github/workflows/tests.yml
jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: ./.github/actions/build
      - name: Run tests
        run: pnpm test:backend:unit

The actions/checkout action checks out your repository so the job can work with it. The ./.github/actions/build step runs your composite action. The final step runs the unit tests. Because the unit tests use a mocked Prisma Client (see part 1), this job needs no database.

Add an integration testing job

Integration tests need a real database. Rather than downloading and configuring Docker Compose, use a GitHub Actions service container, which starts Postgres alongside the job and exposes it on localhost.

Add an integration-tests job with a Postgres service. Before running the tests, push the schema to the database with npx prisma db push:

# .github/workflows/tests.yml
jobs:
  # ...
  integration-tests:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: quotes
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v7
      - uses: ./.github/actions/build
      - name: Push database schema
        run: npx prisma db push
      - name: Run tests
        run: pnpm test:backend:int

A few points:

The postgres:17 service runs a Postgres database. Its env block sets the same credentials and database name as the DATABASE_URL at the top of the workflow.
The options block adds a health check so the job waits for Postgres to be ready. This replaces the wait-for-it.sh script the older approach used.
npx prisma db push applies your schema to the fresh database before the tests run.

Note: The env values here are placeholders for a disposable CI database. Do not put real credentials in a workflow file. Use GitHub Actions secrets for anything sensitive.

Add an end-to-end testing job

The end-to-end tests from part 4 need Postgres, the Playwright browsers, and the frontend and backend running (Playwright starts those via its webServer config).

Add an e2e-tests job. It uses the same Postgres service, installs the Playwright browsers with --with-deps, pushes the schema, and runs the tests:

# .github/workflows/tests.yml
jobs:
  # ...
  e2e-tests:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: quotes
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v7
      - uses: ./.github/actions/build
      - name: Install Playwright browsers
        run: cd e2e && npx playwright install --with-deps
      - name: Push database schema
        run: npx prisma db push
      - name: Run tests
        run: pnpm test:e2e

The npx playwright install --with-deps step downloads the browsers and their system dependencies inside the runner.

Note: In CI, do not run npx playwright show-report at the end of your end-to-end script. That command serves the report on a local server and would keep the job running until it times out. Remove it from any script the CI job calls.

Verify the workflow

Once the workflow is committed and pushed, open a pull request against main. GitHub Actions runs the three jobs and reports their status on the pull request. You can block merges until they pass using branch protection rules in your repository settings.

The commands each job runs (pnpm test:backend:unit, pnpm test:backend:int, and pnpm test:e2e) are the same ones verified throughout this series against Prisma ORM 7.8.

Frequently asked questions

Summary & final thoughts

In this article you learned:

What continuous integration is and why it helps
How to build a GitHub Actions workflow with a reusable build action
How to run unit, integration, and end-to-end tests as separate jobs, using a Postgres service container for the tests that need a database

Over this series you learned the kinds of tests you can write against applications that use Prisma ORM, how to write them, and how to automate them in CI. You can revisit any part: part 1: Mocking, part 2: Unit Testing, part 3: Integration Testing, and part 4: End-to-End Testing.

Looking ahead: Prisma Next is a TypeScript-native rewrite of Prisma ORM, built for AI coding agents and currently in early access. It becomes Prisma 8 at general availability; until then, Prisma 7 stays the production choice. To try it, run npm create prisma@next or read the early access docs.

The Ultimate Guide to Testing with Prisma: CI Pipelines