Overview

Data Observability CI/CD checks run automatically when you open a pull request (PR) that modifies dbt models. The checks give you the information you need to decide whether a change is safe to merge.

Datadog posts the results as a comment on your PR, and the comment updates each time you push new changes. A full report is also available in Datadog, and you get a link to it in the PR comment.

Check types

Impact Lineage

Impact Lineage builds a graph of everything downstream of your changed dbt models. Use it to assess the blast radius of a change before merging. See which tables, dashboards, and other consumers depend on the models you modified, and route review to the right owners.

See Lineage for more detail on how Datadog builds and navigates lineage graphs.

Drift Detection

Drift Detection compares the data produced by your models before and after your changes using a series of statistical checks. Use it to confirm that a model change produces the expected output, or to catch unintended side effects such as significant row-count changes, null-rate shifts, or cardinality changes in a column’s values.

Setup

1. Connect your source control provider and dbt project

1. Connect your source-control provider. CI/CD checks support GitHub and GitLab.
2. Connect the supported data source account where your dbt models run.
3. Connect your dbt Cloud or dbt Core project to Datadog. You can also connect your dbt project while configuring CI/CD checks.

2. Select your dbt project and repository

1. From the CI/CD settings, click Add CI/CD Checks.
2. Select the dbt project you want to add checks for.
3. Select the main job for the project. This is the job with the most knowledge of your dbt schema.
4. If Datadog doesn’t automatically infer the repository from your source-control provider, select it manually.

Advanced settings

If your dbt project doesn’t live at the root of your repository, you can specify the path to your dbt project in the advanced settings.

3. Configure checks

You can enable each check independently. Enabling all checks yields the richest reports.

Impact Lineage

Impact lineage generates a graph of the downstream assets that may be affected by your model changes.

General settings

Drift Detection

Drift detection compares the current state of your data on the branch to a baseline and flags any deviations. Datadog uses the dbt runs from your CI pipeline as the triggers for drift detection checks. For dbt Core, you must send OpenLineage events from your CI job so Datadog receives these runs. See the OpenLineage setup documentation. For dbt Cloud, configure the CI job that runs on pull requests in the CI Job URL setting in the dbt Cloud section.

Datadog must also be able to read the tables your CI job builds to compare them. The role you created during Snowflake setup (DATADOG_ROLE by default) needs USAGE and SELECT on the database your CI job materializes models to. Datadog’s Snowflake integration setup includes a grantFutureAccess procedure that grants this on all current and future tables and views in every schema of a database. Run it for the database your CI job writes to:

CALL grantFutureAccess('<CI_DATABASE>', '<ROLE_NAME>');

If your CI creates an ephemeral, per-pull-request database, call the procedure as part of that provisioning step so each new database is readable. See Snowflake setup for the procedure definition. Without this access, Datadog receives the CI run but cannot query the CI tables, and drift detection fails.

For dbt Core, drift detection also requires the pull request number to be attached to your OpenLineage events through the sourceCodeLocation facet. This requires openlineage-dbt version 1.46.0 or later and the OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__DISABLED=false environment variable. See Set the environment variables. If your dbt Core CI job runs inside a container, it needs additional setup. See the Running your dbt Core CI job in a container section.

General settings

dbt Cloud

dbt Core

Running your dbt Core CI job in a container

If your dbt Core CI job runs inside a container that the CI runner launches (for example, a GitHub Actions workflow that runs the job with docker run), the container does not inherit the git context from the CI runner. As a result, the repository URL, commit SHA, and pull request number are not detected automatically, and the sourceCodeLocation facet is sent without them. Datadog uses these values to match the run to the pull request you opened or updated, so without them no drift results appear on the pull request.

The following example uses GitHub Actions; on other CI providers, the environment variable names differ, but the approach is the same. On the CI runner, read the values and pass them into the container explicitly:

# On the CI runner, before launching the container:
PR_NUMBER=$(jq -r '.pull_request.number'  "$GITHUB_EVENT_PATH")
HEAD_SHA=$(jq -r '.pull_request.head.sha' "$GITHUB_EVENT_PATH")   # the pull request's head commit, not the merge commit
REPO_URL="${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}"

docker run \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__DISABLED=false \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__REPO_URL="$REPO_URL" \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__PULL_REQUEST_NUMBER="$PR_NUMBER" \
  -e OPENLINEAGE__FACETS__SOURCE_CODE_LOCATION__VERSION="$HEAD_SHA" \
  <YOUR_IMAGE> <YOUR_DBT_OL_COMMAND>

The workflow must run when a pull request is opened or updated:

on:
  pull_request:
    types: [opened, synchronize, reopened]

Further reading

Additional helpful documentation, links, and articles:

Data Observability OverviewDOCUMENTATION Data CatalogDOCUMENTATION LineageDOCUMENTATION Quality MonitoringDOCUMENTATION Jobs MonitoringDOCUMENTATION