IMO, your dbt project should always be running with zero warnings.
The easiest way to ensure this is to elevate warnings to errors during the CI process, so that misconfigurations and deprecations are tidied away before merging to main.
My favourite warning-that-should-be-an-error:
Configuration paths exist in your dbt_project.yml file which do not apply to any resources.
This normally indicates that you’ve changed your file structure but forgot to update dbt_project.yml, so your configurations are no longer being applied.
This has always been possible, but it’s better now.
You can use the warn-error flag, but it’s a blunt instrument. In fact, my old CI job used to have to include a redundant seed just to avoid “nothing to do” from derailing my Slim CI seed step.
In dbt 1.4 and higher, you can configure specific warnings to elevate to errors, or elevate everything bar a couple of exclusions.
I like having an env var called DBT_WARN_ERROR_OPTIONS with the value {"include": "all", "exclude": [NothingToDo, NoNodesForSelectionCriteria]} for my CI environment and an empty dict {} for dev and prod environments.
Here’s how that behaves in practice:
