CI/CD pipelines

The problem

A CI database is the easiest place for test data to rot. Teams reach for one of three bad options, and each one costs merges:

• A shared test database. Two branches write to the same rows, tests pass in isolation and fail in the pipeline, and nobody trusts a red build.
• Committed seed SQL. A dump.sql checked into Git, kept in sync by hand. It drifts from the schema the first time someone adds a column, and it silently tests the wrong shape of your data.
• A copy of production. It "just works" until an auditor asks why real customer rows are sitting in a CI container on an ephemeral runner. Test environments rarely hold production's security bar, so a prod dump in CI is a compliance finding waiting to happen.

What CI actually wants is the opposite of all three: a throwaway database, seeded fresh from the current schema, on every run.

Generate the data, don't copy it

Weavori reads your schema and produces the rows inside your pipeline. No dump files to maintain, no production data to move, and a run that takes seconds instead of a restore job.

• One command, no config. npx @weavori/cli generate, pinned to a version, with the API key from your secret store. Nothing to map per column.
• Referential integrity by construction. Weavori resolves foreign-key order and writes parents before children, so a seeded CI database never trips a constraint.
• Works with any ephemeral database. GitHub Actions and GitLab service containers, CircleCI images, Jenkins, or Testcontainers. If it exposes a Postgres port, Weavori fills it.
• Deterministic when you need it. Pass --seed to replay the exact same rows across runs, so a flaky test stays reproducible and snapshot fixtures stay stable.

Drop it into a pipeline

The whole integration is two steps after your migrations run: seed, then test.

A minimal GitHub Actions job looks like this. The CI/CD guide has the GitLab, CircleCI, Jenkins, and matrix-testing versions.

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env: { POSTGRES_USER: test, POSTGRES_PASSWORD: test, POSTGRES_DB: test }
        ports: ["5432:5432"]
        options: >-
          --health-cmd="pg_isready -U test"
          --health-interval=5s
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "22" }
      - run: npx --yes @weavori/cli@0.1.6 generate "$SOURCE_DB" --target "$TARGET_DB" --yes --output plain
        env:
          WEAVORI_API_KEY: ${{ secrets.WEAVORI_API_KEY }}
          SOURCE_DB: ${{ secrets.SOURCE_DB }}
          TARGET_DB: postgres://test:test@localhost:5432/test
      - run: go test ./...

Fails the way CI needs it to

A good pipeline step is quiet when it works and loud when it doesn't. --output plain streams one line per table, and the CLI returns a semantic exit code, so the job gates on the result instead of parsing prose.

If a run can't complete, the exit code tells your pipeline why, so an auth problem never looks like a test failure:

Pre-flight a PR without writing a single row

Before you spend build minutes on a schema change, use estimate as a read-only gate. It confirms connectivity, introspects the schema, and reports the estimated generation time without generating or writing anything, safe to run on every pull request.

Get started