Hosted or self-managed/dbt-core 1.12/MetricFlow 0.15

All posts

Slim CI, explained: only rebuilding what a pull request actually changed

Engineering/July 15, 2025/3 min read

Running a full dbt build on every pull request works fine when a project has twenty models. At two hundred models it means every PR waits ten or fifteen minutes for a build that mostly rebuilds things the PR never touched, and people start merging without waiting for CI at all, which defeats the point of having it.

Slim CI builds state:modified+ instead: the models a PR actually changed, plus everything downstream of them, deferring to production for everything else. A one-line change to a staging model triggers a build of that model and whatever depends on it, not the other 180 models sitting untouched three layers upstream.

What triggers it, and what doesn't

CI jobs start when a non-default branch is pushed from Forewarden's Git panel, and build into a per-branch schema so two branches never share test data. Merge jobs start when the default branch is pushed. If the project has an https github.com remote with a stored access token, Forewarden posts the result as a GitHub commit status on that commit. Pushes made directly to GitHub do not start a CI job.

The models this doesn't help: a change to a source's raw table structure still has to propagate through everything downstream of it, the same as it would with a full build. Slim CI narrows the blast radius of what a PR changed; it doesn't change what depends on what.

Connect a warehouse. Build your first models this afternoon.

Start with a managed repository and a starter project, or start from a warehouse you already have. On a self-managed deployment an administrator can also connect an existing repository. Thirty days, no card on file.