dbt™️ checks

check-macro-has-meta-keys

What it does

Ensures that the macro has a list of valid meta keys. (usually schema.yml).

When to use it

If every macro needs to have certain meta keys.

By default, it does not allow the macro to have any other meta keys other than the ones required. An optional argument can be used to allow for extra keys.

Arguments

--manifest: location of manifest.json file. Usually target/manifest.json. This file contains a full representation of dbt project. Default: target/manifest.json --meta-keys: list of the required keys in the meta part of the macro. --allow-extra-keys: whether extra keys are allowed. Default: False.

Example

repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-macro-has-meta-keys
        args: ['--meta-keys', 'foo', 'bar', "--"]

⚠️ do not forget to include -- as the last argument. Otherwise pre-commit would not be able to separate a list of files with args.

Requirements

Macro exists in manifest.json 1	Macro exists in catalog.json 2
✅ Yes	❌ Not needed

1 It means that you need to run dbt parse before run this hook (dbt >= 1.5). 2 It means that you need to run dbt docs generate before run this hook.

How it works

• Hook takes all changed yml files.

• The manifest is scanned for a macro.

• If any macro (from a manifest or yml files) does not have specified meta keys, the hook fails.

• The meta keys must be in either the yml file or the manifest.

Known limitations

If you run your macro and then you delete meta keys from a properties file, the hook success since the meta keys is still present in manifest.json.

---

check-seed-has-meta-keys

What it does

Ensures that the seed has a list of valid meta keys. (usually schema.yml).

When to use it

If every seed needs to have certain meta keys.

By default, it does not allow the seed to have any other meta keys other than the ones required. An optional argument can be used to allow for extra keys.

Arguments

--manifest: location of manifest.json file. Usually target/manifest.json. This file contains a full representation of dbt project. Default: target/manifest.json --meta-keys: list of the required keys in the meta part of the seed. --allow-extra-keys: whether extra keys are allowed. Default: False.

Example

repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-seed-has-meta-keys
        args: ['--meta-keys', 'foo', 'bar', "--"]

⚠️ do not forget to include -- as the last argument. Otherwise pre-commit would not be able to separate a list of files with args.

Requirements

Seed exists in manifest.json 1	Seed exists in catalog.json 2
✅ Yes	❌ Not needed

1 It means that you need to run dbt parse before run this hook (dbt >= 1.5). 2 It means that you need to run dbt docs generate before run this hook.

How it works

• Hook takes all changed yml files.

• The manifest is scanned for a seed.

• If any seed (from a manifest or yml files) does not have specified meta keys, the hook fails.

• The meta keys must be in either the yml file or the manifest.

Known limitations

If you run your seed and then you delete meta keys from a properties file, the hook success since the meta keys is still present in manifest.json.

---

check-snapshot-has-meta-keys

What it does

Ensures that the snapshot has a list of valid meta keys. (usually schema.yml).

When to use it

If every snapshot needs to have certain meta keys.

By default, it does not allow the snapshot to have any other meta keys other than the ones required. An optional argument can be used to allow for extra keys.

Arguments

--manifest: location of manifest.json file. Usually target/manifest.json. This file contains a full representation of dbt project. Default: target/manifest.json --meta-keys: list of the required keys in the meta part of the snapshot. --allow-extra-keys: whether extra keys are allowed. Default: False.

Example

repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-snapshot-has-meta-keys
        args: ['--meta-keys', 'foo', 'bar', "--"]

⚠️ do not forget to include -- as the last argument. Otherwise pre-commit would not be able to separate a list of files with args.

Requirements

Snapshot exists in manifest.json 1	Snapshot exists in catalog.json 2
❌ Not	❌ Not needed

1 It means that you need to run dbt parse before run this hook (dbt >= 1.5). 2 It means that you need to run dbt docs generate before run this hook.

How it works

• Hook takes all changed yml and sql files.

• The manifest is scanned for a snapshot.

• If any snapshot (from a manifest or yml files) does not have specified meta keys, the hook fails.

• The meta keys must be in either the yml file or the manifest.

Known limitations

If you run your snapshot and then you delete meta keys from a properties file, the hook success since the meta keys is still present in manifest.json.

---

check-test-has-meta-keys

What it does

Ensures that the test has a list of valid meta keys. (usually schema.yml).

When to use it

If every test needs to have certain meta keys.

By default, it does not allow the test to have any other meta keys other than the ones required. An optional argument can be used to allow for extra keys.

Arguments

--manifest: location of manifest.json file. Usually target/manifest.json. This file contains a full representation of dbt project. Default: target/manifest.json --meta-keys: list of the required keys in the meta part of the test. --allow-extra-keys: whether extra keys are allowed. Default: False.

Example

repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-test-has-meta-keys
        args: ['--meta-keys', 'foo', 'bar', "--"]

⚠️ do not forget to include -- as the last argument. Otherwise pre-commit would not be able to separate a list of files with args.

Requirements

Test exists in manifest.json 1	Test exists in catalog.json 2
❌ Not	❌ Not needed

1 It means that you need to run dbt parse before run this hook (dbt >= 1.5). 2 It means that you need to run dbt docs generate before run this hook.

How it works

• Hook takes all changed sql files.

• The manifest is scanned for a test.

• If any test (from a manifest or sql files) does not have specified meta keys, the hook fails.

• The meta keys must be in either the yml file or the manifest.

Known limitations

If you run your test and then you delete meta keys from a properties file, the hook success since the meta keys is still present in manifest.json.

---

check-database-casing-consistency

What it does

compare Manifest and Catalog to ensure DB and Schemas have the same casing.

When to use it

If you want to make sure your dbt project (Manifest) and database (Catalog) are db.schema consistent

Arguments

--manifest: location of manifest.json file. Usually target/manifest.json. This file contains a full representation of dbt project. Default: target/manifest.json --catalog: location of catalog.json file. Usually target/catalog.json. dbt uses this file to render information like column types and table statistics into the docs site. In dbt-checkpoint is used for column operations. Default: target/catalog.json

Example

repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-database-casing-consistency

How it works

It compares models and sources databases and schemas in manifest vs catalog. If a db/schema in one of them presents a different casing, the hook fails.