Hurrah! So let me repeat this back and check I’ve got it (I’ve turned this into a Wiki post, so you can edit it directly if I’ve got anything wrong, then I’ll mark it as the solution and use it as the bones of a GH issue)
- By default, dbt snapshots build into a hardcoded schema. Making the schema dynamic means that every snapshot is considered
state:modifiedon every CI run because in-file environmentally-aware configs trigger false positives andtarget_schemacan’t be defined indbt_project.yml. - You can make a zero-copy clone of the snapshot to a different database at the start of a CI run.
target_databasecan be defined usingenv_varjinja in thesnapshotssection ofdbt_project.ymlwhich means other unchanged snapshots don’t get picked up as modified unnecessarily. - Cloning to a different database as described in the second bullet and then setting the snapshot database environment variable in your SlimCI job enables snapshots to be Slim CI’d. If you can’t do that, you’d need to exclude them from the CI job definition. That is tricky in
dbt buildcontext because thedbt build --resource-typefilter seems to only takes a single resource type anyway, and it’s not able to be used for exclusion)