Support Enforcement of Descriptions and Tests as a Config Option

[tnightengale]

Describe the feature

Would anyone be interested in config settings, that could enforce documentation and tests for models? Eg.

# dbt_project.yml
name: 'my_project'
version: '1.0.0'
...
models:
  my_project:
      +require_descriptions: true
      +required_tests:
          - not_null
          - unique
...

and models in the resource path with empty descriptions or without the required tests will result in a failed run/compilation?
Currently we implement these approaches with custom scripts in our CI that parse the manifest.json. I think it would be wonderful if these became builtin options for others to use easily.

Describe alternatives you've considered

Basically parsing the manifest with a python script in the CI. This is sort of a hack.

Who will this benefit?

Adding this optionality in reduces the onus on reviewers to call out missing docs/tests. This helps teams who want to really automate their deployments of dbt. Ideally to the point that something is in the prod database/schema etc as soon as it is merged.

Allowing the option to enforce tests/docs along model paths reduces unnecessary dialogue on PRs: if the CI passes, and these options are enabled, then the submitter has already done their diligence.

Are you interested in contributing this feature?

I am interested in working on this, and am creating this ticket to get feedback and track work on it.

[jtcohen6]

Hmmm. Interesting idea! Thanks for writing up this detailed proposal, @tnightengale. I'd be really curious to hear what other community members think. Here are my two cents:

1. I agree that enforcing expectations for test and documentation coverage is highly valuable in CI. But... I could see this as being such a pain in development, when you write a model and go to run it only to find that you first have to supply a dummy description and tests on an arbitrary column. (Nothing worse than forgetting to remove those dummy entries, and later catching in PR review or CI checks.) Nor am I a big fan of this answer:

  my_project:
      +require_descriptions: "{{ 'true' if target.name != 'dev' else 'false' }}"

2. This feels like add-on tooling. I see it in the same category as linters and code generators (e.g. codegen, dbt-helper), which totally have a place in the dbt ecosystem but not in the dbt core codebase per se.

Basically parsing the manifest with a python script in the CI. This is sort of a hack.

I think this feels hackier today than it really is, or ultimately should be. We're stabilizing and documenting the schema of the manifest in dbt v0.19.0. I would love nothing more than for these scripts to be open sourced and widely tested.

I believe that such a check could even be written as a Jinja macro. In that case it could be (a) executed as a run-operation within a CI job definition, and (b) open sourced as a dbt package, and pinned to supported dbt versions.

[noel]

This exists already via this option
https://github.com/offbi/pre-commit-dbt
or this option
https://github.com/tnightengale/dbt-meta-testing

[tnightengale]

Yeah, I opened it before writing dbt-meta-testing 😁

[jtcohen6]

I just converted this issue to a discussion, which I think cannot actually be closed, but happy to have this be the top-upvoted answer :)

Maybe someday dbt-core wants to have this sort of metadata-enforcement capability built in. For now, I'm happy with its role being to supply metadata (via contracted interface) that can enable other tools for reporting/governance/etc