¿Cómo evito que cada CI reconstruya todo mi proyecto dbt?

Un proyecto dbt con 40 modelos y otro con 400 ejecutan exactamente el mismo dbt build - y pagan facturas de CI muy distintas por ello, a menos que algo le diga a dbt qué cambió.

Qué compara realmente la selección basada en estado

dbt escribe un manifest.json después de cada ejecución exitosa, que describe por completo el SQL compilado de cada modelo y su lugar en el DAG. --select state:modified+ compara el manifest actual contra uno guardado que usted indica, y construye solo los modelos cuyo SQL compilado realmente cambió, más todo lo que depende de ellos aguas abajo.

Por qué esto silenciosamente nunca se activa

La razón más común por la que la selección por estado no hace nada: CI nunca guardó ni descargó el manifest de la ejecución anterior, así que --state no tiene con qué comparar. dbt no da error por esto - simplemente no puede encontrar modelos modificados respecto a nada, y la build hace todo en silencio. Arreglarlo significa tratar manifest.json como un artefacto de CI que se sube después de cada ejecución de producción exitosa y se descarga al inicio de la siguiente.

El otro asesino silencioso: el hábito del full-refresh

Una bandera --full-refresh dejada en el comando de CI "por si acaso" reconstruye cada modelo incremental desde cero sin importar lo que haya encontrado la selección por estado - ignora el diff por completo para esos modelos. Ese valor por defecto suele ser un resto de haber depurado un modelo incremental roto alguna vez, nunca eliminado. Reserve --full-refresh para una ejecución explícita y deliberada sobre un modelo, no como bandera fija de CI.