← ClaudeAtlas

dbt-ci-governancelisted

Design a dbt CI pipeline that gates every pull request: compile, run, test, and check source freshness in an isolated developer schema; enforce model contracts on published marts; run slim CI on changed models only using dbt state comparison; and block merges on test failures or contract violations.
mcorbett51090/RavenClaude · ★ 7 · AI & Automation · score 65
Install: claude install-skill mcorbett51090/RavenClaude
# Skill: dbt-ci-governance **Purpose:** Build the CI gate that enforces data quality and schema contracts before any dbt model reaches production. Used by `analytics-engineer` (pipeline design) and `data-quality-testing-engineer` (test gate and contract enforcement). ## When to use - Setting up CI for a new dbt project. - Adding a CI gate to an existing project that only runs `dbt compile`. - Enforcing model contracts on published mart boundaries. - Reducing CI cost on large projects by running only changed models (slim CI). --- ## The dbt CI gate — what must run on every PR A CI pipeline that only runs `dbt compile` is not a CI gate — it proves only that the SQL is syntactically valid. A real gate runs in this order: | Step | Command | Fails on | Why it's required | |---|---|---|---| | 1. Compile | `dbt compile` | Syntax errors, missing refs | Fastest check; catches broken references | | 2. Source freshness | `dbt source freshness` | Stale source data | Prevents building on yesterday's data | | 3. Build (run + test) | `dbt build --select state:modified+` | Model failures, test failures | Proves the models and their tests pass | | 4. Contract check | `dbt build --select state:modified+` with contracts enabled | Column drops, type changes on mart models | Prevents breaking downstream consumers | **On small projects (< 50 models):** run `dbt build` against all models. On large projects, use slim CI (step 3 above uses `state:modified+`) to keep CI time under 10 minutes.