Skip to main content
When you open a pull request in a dbt™ project that other projects depend on, Lineage Diff also lists the impacted nodes in those consumer projects, across your Paradime workspaces.

​
Key benefits

  1. Identify which dbt™ model changes affect the projects that depend on yours.
  2. Tell the owners of affected downstream models and exposures before your changes reach production.
  3. Discover which cross-project dependencies a change might break.

​
Prerequisites

  1. Complete the Lineage Diff prerequisites for the producer project, the project you open pull requests in.
  2. Connect your projects with cross-project dependencies. Lineage Diff finds a project’s consumers through their dbt_loom.config.yml files, so the name in each consumer’s file must match the producer’s project name.
  3. In each consumer workspace, create a Bolt schedule with these settings:
    1. Name: paradime_dbt_mesh
    2. Command: dbt compile
    3. Trigger: Scheduled, for example hourly, or On merge
Lineage Diff reads each consumer’s compiled models from the latest run of its paradime_dbt_mesh schedule, so keep the command dbt compile and keep the schedule running. The producer workspace doesn’t need this schedule unless it also consumes another project.

​
How to use

When a PR is opened in GitHub, an automated comment lists the downstream dbt™ Mesh nodes (projects, models, exposures, sources, and more) that the change would impact. Use the links in each dbt nodes impacted section to investigate each node in its dbt™ project before you merge the PR.
A Paradime Column-Level Lineage Analysis comment on a GitHub pull request, listing impacted dbt nodes in platform_dbt_project and ops_dbt_project for a change to models/staging/stg_payments.sql
If the comment has no dbt™ Mesh section, check that each consumer’s paradime_dbt_mesh schedule has a recent successful run, and that every workspace’s dbt_loom.config.yml is valid YAML. One unreadable file can stop the section from appearing.