dbt slim CI builds more models than the pull request changed

A small dbt pull request starts a large CI build, or unexpectedly skips a model. A dbt Community discussion shows how quickly a team can lose confidence in “slim” CI when the selected graph is opaque. The first step is to inspect the comparison state, not to weaken tests.

Name the baseline being compared

dbt CI compares the pull request with a production state and builds modified assets plus downstream dependencies in an isolated schema. Record the deferred environment, last successful production job, manifest generation time and PR commit. A stale or missing baseline changes what “modified” means.

Explain the selector as a graph

Review the actual command and selector, including a trailing + that includes descendants. dbt deferral guidance distinguishes state selection from resolving unbuilt parents against another environment. Generate and review the selected node list before the expensive build; compare a supposedly surprising model’s dependency path to the changed node.

Check the run’s purpose

A scheduled deploy job and a PR CI job have different objectives. dbt warns that state:modified on a scheduled job may complete with zero models when no code changed, even if source data did. Keep code-change selection for CI; make data-refresh behavior explicit in production scheduling.

Adovo’s view

Fast CI is useful only when engineers can explain what was tested. Preserve the manifest, selector and selected-node list as release evidence so “green” means a known slice of the data contract passed.