Evaluating SQL Yodeler

For someone deciding whether SQL Yodeler fits: two finished example projects, the claims that run against real servers, and a first migration on a local database.

Works

• Two example projects, one per dialect, whose READMEs are transcripts of real runs
• Scenario claims that run each feature against a real server, plain and with the behaviour broken
• Your first migration on chant's local emulator, with no cloud account

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

ClickHouse

npx @intentius/sql-yodeler@latest create my-schema --clickhouse --database events

Postgres

npx @intentius/sql-yodeler@latest create my-schema --postgres --schema app

Your first migration

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
new	yodel new writes the next migration offline, with no dev database, and it applies; on Postgres, functions, procedures and triggers too, which lint checks	ClickHouse: pass, caughtPostgres: pass, caught
template	a project from the starter template, on Forgejo: apply only after approval, lint with replay and the plan comment on a pull request, and the approved change applied on merge; a sealed wave applies only on an approval sealed by a signer listed at the base, and a pr-review wave on the review of a writer other than the author; a pull request job cannot write, a forked migration fails lint and is annotated, a stale or hand-edited pipeline fails yodel ci --check, the CI image pinned by digest runs a pull request's jobs, a command token source mints the reader's password, and the drift watch keeps one tracking issue	ClickHouse: pass, caughtPostgres: pass, caught
template-github	a project from the starter template, on GitHub Actions (act and a mock GitHub): apply only after approval, lint with replay and the plan comment on a pull request, and the approved change applied on merge; a sealed wave applies only on an approval sealed by a signer listed at the base, and a pr-review wave on the review of a writer other than the author; a pull request job cannot write, a forked migration fails lint and is annotated, a stale or hand-edited pipeline fails yodel ci --check, the CI image pinned by digest runs a pull request's jobs, a command token source mints the reader's password, and the drift watch keeps one tracking issue	ClickHouse: pass, caughtPostgres: pass, caught

Then read

Tasks

Your first migration

Background

The ClickHouse exampleThe Postgres exampleThe two workflows

Reference

Claims statusThe commands