Check configurations
Related documentation
Available configurations
- Project YAML file
- Properties YAML file
- SQL config
checks/_checks.yml
version: 2
checks:
- name: check-name
config:
severity: error | warn
enabled: true | false
selection_filter_on: column_name | [column_names] | none
tags: string | [string]
meta: {dictionary}
checks/<check_name>.sql
{{ config(
severity = "error" | "warn",
enabled = true | false,
selection_filter_on = "column_name" | ["column_names"] | "none",
tags = ["string"],
meta = {"key": "value"}
) }}
select ...
from {{ info_schema('models') }}
where ...
Examples
The following examples show common ways to configure checks.
Warn on check failure
You can use severity: warn when rolling out a new rule gradually. Issues are logged but the build does not fail.
checks/_public_models_have_owners.yml
checks:
- name: public_models_have_owners
config:
severity: warn # default is error
Filter by a specific column
The edges table has no unique_id column, so checks that query it won't return one. When you use --select, dbt looks for a unique_id column to scope results and finds none, so the check runs against the whole project regardless of the selector. Set selection_filter_on to the columns that contain resource IDs so --select scopes rows by those columns. For example, the multiple_sources_joined check aggregates by child_unique_id, so only that column needs to be set:
checks/_multiple_sources_joined.yml
checks:
- name: multiple_sources_joined
config:
selection_filter_on: child_unique_id
Was this page helpful?
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
0