Dbt-dry-run

Improvements & Bugfixes

- Support dry running tests. Generic and custom tests will be checked. This can catch errors such as column name typos in the
generic test metadata and SQL syntax errors in custom tests

- Added support for `dbt-external-tables`. Any `source` marked with `external` will be 'dry runned' by reading the
schema from the yaml metdata for the source. The dry run does not support schema prediction for external tables

Bugfixes

- Fixed issue where using a SQL header and `_dbt_max_partition` in an incremental would cause a false positive dry run
failure due to `Variable declarations are allowed only at the start of a block or script`

Improvements & Bugfixes

- Add support for column metadata linting/validation. Mark a model in its metadata with `dry_run.check_columns: true`
to enable checks that ensure that column names in the predicted dbt project schema match the columns in the metadata
see the `README.md` for more info, failure will be reporting as a `LINTING` error:

text
Dry running X models
Node model.test_column_linting.badly_documented_model failed linting with rule violations:
UNDOCUMENTED_COLUMNS : Column not documented in metadata: 'c'
EXTRA_DOCUMENTED_COLUMNS : Extra column in metadata: 'd'

Total 1 failures:
1 : model.test_column_linting.badly_documented_model : LINTING : ERROR
DRY RUN FAILURE!

Improvements & Bugfixes

- Add support for dbt v1.3.0

- Throw error if dbt project uses python models as these cannot be used with the dry run as we cannot currently predict
their schemas

Improvements & Bugfixes

- Allow `unique_key` to be a list of strings for incremental models which was added in `dbt v1.1`

Improvements & Bugfixes

- Under the hood re-write of how we create the BigQuery connection. We now directly interact with dbt and create the
project config and BigQuery adapter using dbt instead of reimplementing the logic that dbt uses by reading your
`profiles.yml`

- Due to the re-write there is backwards incompatible changes with the CLI where you should now run the dry runner in
the same way use run `dbt compile` as it will search for the `dbt_project.yml` in the same directory as you run the
dry runner (By default). This can be overridden in the same way as in dbt using the `--project-dir` option

- The CLI now also uses [Typer][get-typer] so the CLI help is now improved. Typing `dbt-dry-run --help` outputs:


❯ dbt-dry-run --help
Usage: dbt-dry-run [OPTIONS] [PROFILE]

Options:
--profiles-dir TEXT [dbt] Where to search for `profiles.yml`
[default: /Users/<user>/.dbt]
--project-dir TEXT [dbt] Where to search for `dbt_project.yml`
[default: /Users/<user>/Code/dbt-
dry-run]
--vars TEXT [dbt] CLI Variables to pass to dbt
--target TEXT [dbt] Target profile
--verbose / --no-verbose Output verbose error messages [default: no-
verbose]
--report-path TEXT Json path to dump report to
--install-completion [bash|zsh|fish|powershell|pwsh]
Install completion for the specified shell.
--show-completion [bash|zsh|fish|powershell|pwsh]
Show completion for the specified shell, to
copy it or customize the installation.
--help Show this message and exit.



Where any option description prefixed with `[dbt]` should work in the same way as it does in the dbt CLI

- Fixed issue where `partition_by` `data_type` was case-sensitive so a value of `DATE` would not be accepted by the
dry runner but would be accepted by dbt when parsing the manifest