Directories#
Note
The below checks require manifest.json to be present.
Checks related to model file locations, names, and directory structure.
Functions:
| Name | Description |
|---|---|
check_model_directories |
Only specified sub-directories are permitted. |
check_model_file_name |
Models must have a file name that matches the supplied regex. |
check_model_has_properties_file |
Models must be declared in a properties file, i.e. a |
check_model_property_file_location |
Model properties files must follow the configured layout. |
check_model_schema_name |
Models must have a schema name that matches the supplied regex. |
check_model_directories
#
Only specified sub-directories are permitted.
Rationale
A well-structured dbt project organises models into predictable directories (e.g. staging, intermediate, marts). Enforcing permitted sub-directories prevents ad-hoc folders from proliferating, making the project layout consistent and navigable for all contributors.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
include
|
str
|
Regex pattern matched against the start of each model's file path. Models outside this directory are skipped entirely, and the directory immediately after the matched prefix is what gets validated against |
required |
permitted_sub_directories
|
list[str]
|
List of permitted sub-directories. |
required |
Receives at execution time:
| Name | Type | Description |
|---|---|---|
model |
ModelNode
|
The ModelNode object to check. |
Other Parameters (passed via config file):
| Name | Type | Description |
|---|---|---|
description |
str | None
|
Description of what the check does and why it is implemented. |
exclude |
str | list[str] | None
|
Regex pattern(s) to match the model path. Model paths that match any pattern will not be checked. |
materialization |
Literal[ephemeral, incremental, table, view] | None
|
Limit check to models with the specified materialization. |
severity |
Literal[error, warn] | None
|
Severity level of the check. Default: |
Example(s):
manifest_checks:
- name: check_model_directories
include: models
permitted_sub_directories:
- intermediate
- marts
- staging
# Restrict sub-directories within `./models/staging`
- name: check_model_directories
include: ^models/staging
permitted_sub_directories:
- crm
- payments
Source code in src/dbt_bouncer/checks/manifest/models/directories.py
check_model_file_name
#
Models must have a file name that matches the supplied regex.
Rationale
Consistent file naming conventions (e.g. including a version suffix for mart models) make it easy to identify a model's purpose and layer at a glance. Enforcing naming patterns in CI prevents deviations that accumulate over time and make the project harder to navigate.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
file_name_pattern
|
str
|
Regexp the file name must match. Please account for the |
required |
Receives at execution time:
| Name | Type | Description |
|---|---|---|
model |
ModelNode
|
The ModelNode object to check. |
Other Parameters (passed via config file):
| Name | Type | Description |
|---|---|---|
description |
str | None
|
Description of what the check does and why it is implemented. |
exclude |
str | list[str] | None
|
Regex pattern(s) to match the model path. Model paths that match any pattern will not be checked. |
include |
str | list[str] | None
|
Regex pattern(s) to match the model path. Only model paths that match any pattern will be checked. |
materialization |
Literal[ephemeral, incremental, table, view] | None
|
Limit check to models with the specified materialization. |
severity |
Literal[error, warn] | None
|
Severity level of the check. Default: |
Example(s):
manifest_checks:
- name: check_model_file_name
description: Marts must include the model version in their file name.
include: ^models/marts
file_name_pattern: .*(v[0-9])\.sql$
Source code in src/dbt_bouncer/checks/manifest/models/directories.py
check_model_has_properties_file
#
Models must be declared in a properties file, i.e. a .yml file.
Rationale
A model with no properties file has nowhere to hang a description, column definitions, tests, contracts, or meta keys. It is invisible to the generated documentation and cannot be covered by any of the checks that read those fields, so gaps in it go unnoticed rather than being reported. Requiring a properties file is the precondition for every other documentation and testing convention a project wants to enforce.
check_model_property_file_location also reports undocumented models, but only as a side effect of enforcing dbt Labs' _<directory>__models.yml naming convention. Use this check instead if you want to require a properties file without adopting that convention.
Receives at execution time:
| Name | Type | Description |
|---|---|---|
model |
ModelNode
|
The ModelNode object to check. |
Other Parameters (passed via config file):
| Name | Type | Description |
|---|---|---|
description |
str | None
|
Description of what the check does and why it is implemented. |
exclude |
str | list[str] | None
|
Regex pattern(s) to match the model path. Model paths that match any pattern will not be checked. |
include |
str | list[str] | None
|
Regex pattern(s) to match the model path. Only model paths that match any pattern will be checked. |
materialization |
Literal[ephemeral, incremental, table, view] | None
|
Limit check to models with the specified materialization. |
severity |
Literal[error, warn] | None
|
Severity level of the check. Default: |
Example(s):
Source code in src/dbt_bouncer/checks/manifest/models/directories.py
check_model_property_file_location
#
Model properties files must follow the configured layout.
Rationale
Property files are only easy to find if their location is predictable. Two conventions are common. per_directory is dbt's official guidance: one file per directory, named after the directory it documents (e.g. _staging_crm__models.yml). per_model gives each model its own file named after it (e.g. stg_customers.yml), which keeps diffs small and avoids merge conflicts when several people edit different models at once. Either works; mixing them within a project does not.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
layout
|
Literal[per_directory, per_model]
|
The properties file layout to enforce. |
PER_DIRECTORY
|
Receives at execution time:
| Name | Type | Description |
|---|---|---|
model |
ModelNode
|
The ModelNode object to check. |
Other Parameters (passed via config file):
| Name | Type | Description |
|---|---|---|
description |
str | None
|
Description of what the check does and why it is implemented. |
exclude |
str | list[str] | None
|
Regex pattern(s) to match the model path. Model paths that match any pattern will not be checked. |
include |
str | list[str] | None
|
Regex pattern(s) to match the model path. Only model paths that match any pattern will be checked. |
materialization |
Literal[ephemeral, incremental, table, view] | None
|
Limit check to models with the specified materialization. |
severity |
Literal[error, warn] | None
|
Severity level of the check. Default: |
Example(s):
Source code in src/dbt_bouncer/checks/manifest/models/directories.py
143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 | |
check_model_schema_name
#
Models must have a schema name that matches the supplied regex.
Rationale
Consistent schema naming (e.g. stg_payments for staging models or intermediate for intermediate ones) makes it clear where a model lives in the transformation pipeline without inspecting its SQL. This also prevents models from landing in unexpected schemas in production due to misconfigured dbt_project.yml settings.
Note that most setups will use schema names in development that are prefixed, for example: * dbt_jdoe_stg_payments * mary_stg_payments
Please account for this if you wish to run dbt-bouncer against locally generated manifests.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
schema_name_pattern
|
str
|
Regexp the schema name must match. |
required |
Receives at execution time:
| Name | Type | Description |
|---|---|---|
model |
ModelNode
|
The ModelNode object to check. |
Other Parameters (passed via config file):
| Name | Type | Description |
|---|---|---|
description |
str | None
|
Description of what the check does and why it is implemented. |
exclude |
str | list[str] | None
|
Regex pattern(s) to match the model path. Model paths that match any pattern will not be checked. |
include |
str | list[str] | None
|
Regex pattern(s) to match the model path. Only model paths that match any pattern will be checked. |
materialization |
Literal[ephemeral, incremental, table, view] | None
|
Limit check to models with the specified materialization. |
severity |
Literal[error, warn] | None
|
Severity level of the check. Default: |
Example(s):
manifest_checks:
- name: check_model_schema_name
include: ^models/intermediate
schema_name_pattern: .*intermediate # Accounting for schemas like `dbt_jdoe_intermediate`.
- name: check_model_schema_name
include: ^models/staging
schema_name_pattern: .*stg_.*