Lint and plan on pull requests

For a team that wants every migration reviewed in its pull request before SQL Yodeler applies anything.

Works

• yodel lint and the replay check on every pull request, with no database credentials
• A plan comment per environment, made with read-only credentials, and a write probe that fails the job if they can write
• The drift watch on its schedule, with a tracking issue
• No apply pipeline and no writer in CI until you turn apply on

Differs

By database

ClickHouse

• A project owns ClickHouse databases (yodel create <dir> --clickhouse --database <name>).
• A rebuild keeps the old table until yodel cleanup drops it, and lint flags mutations and rebuilds (ch-mutation, ch-rebuild).

Postgres

• A project owns Postgres schemas (yodel create <dir> --postgres --schema <name>).
• Roles stay the environment's: the schema declares the policies and grants that name them.

By forge

GitHub

• The writer's secrets are secrets of a GitHub environment limited to main.
• The plan comment and the drift issue use the job's own token.

GitLab

• The writer's variables are protected and scoped to the environment; the readers' are not protected.
• The plan comment and the drift issue need GITLAB_TOKEN, and each drift watch runs from a pipeline schedule you create.

Forgejo

• Secrets belong to the repository, with no environments, so limit who can push branches.
• Jobs need a runner with the docker label, and a job gets no OIDC token for cloud roles.

First step

Set ci: { forges: ["github", "gitlab", "forgejo"], apply: false } in yodel.config.ts, then render the pipelines:

npm run ci

Lint and plan on pull requests only

Proof

Each claim runs what this room relies on against a real server, once plain (it passes) and once with the behaviour broken (the claim catches it). Claims status lists every claim.

Claim	What it says	Plain, broken
lint	yodel lint --replay replays the migrations into a fresh database and each gives the schema it recorded; offline, yodel lint fails a migrations directory with a fork (exit 3), naming both migrations; a checkpoint replays alone to its recorded schema, and a fresh environment starts from it; yodel revert undoes the newest migration behind the gate, with a hand-written step for its data step, back to its parent's recorded schema, and refuses a checkpoint or a migration before one; yodel test runs a project's tests on databases replayed from the migrations, a seed meeting the backfill after it, fails a case whose assertion does not hold, and refuses an environment with a history; on Postgres, a unique index over rows with duplicates is refused before the gate by its generated pre-check (exit 4, naming the statement and the count), and yodel lint flags it as data-dependent	ClickHouse: pass, caughtPostgres: pass, caught
pr-comment	the pull request comment lists the pending migrations with each statement's class, and the digest the gate asks for	ClickHouse: pass, caughtPostgres: pass, caught

Then read

Tasks

Lint and plan on pull requests onlySetting up each forge

Background

LintThe pull request commentDrift

Reference

The commandsThe lint rules