dbt Impact Analysis GitLab Component

When a merge request changes dbt models, the dbt Impact Analysis GitLab CI/CD component uses Sifflet's lineage to list the tables, views, and dashboards downstream of these models, and posts this list as a merge request comment.

This page describes what the component does and what its report contains. To set it up, see Connect Sifflet to GitLab; its inputs are documented in Step 3.

How It Works

The component adds a dbt-impact-analysis-job job to your pipeline. By default, this job runs in merge request pipelines only, and is allowed to fail. Each time it runs, it:

1. Lists the files changed by the merge request, and keeps the .sql files. The name of each file, without .sql, is taken as the name of a dbt model.
2. Finds the dbt project of each model: it reads the name of the closest dbt_project.yml file, in the directory of the model or in a parent directory.
3. Asks Sifflet for the assets downstream of each model, in the lineage of the matching dbt source, filtered by the impacted_asset_types and impacted_tags inputs.
4. Posts the report as a new comment on the merge request.

When no .sql file changed, the job ends without posting a comment.

Impact Report

The comment is titled Sifflet Impact Report. It gives the number of changed dbt models and the number of distinct downstream assets they can impact, then, for each changed model:

• a link to the model in Sifflet, and the number of assets it can impact;
• a table of these assets, with their source type (for example Snowflake or Tableau), their asset type (for example Table, View, or Dashboard), and a link to each asset in Sifflet.

The report lists downstream tables, views, and dashboards. It doesn't list downstream dbt models. A model that Sifflet can't match appears as <MODEL_NAME> not found in Sifflet.

The comment looks as follows:

Limitations

• The impact is computed at the asset level: the report can list assets that don't use the fields you modify.
• The impact is computed from changed model files only: changes to macros aren't detected.
• Every changed .sql file is treated as a model, including analyses and SQL tests. Files that don't match a model in Sifflet appear as not found.
• Sifflet must find exactly one dbt model with this project and model name. When several dbt sources in Sifflet contain the same dbt project (for example one source per dbt target), the model appears as not found.
• Each run posts a new comment: pushing new commits to a merge request adds a new report.