[Feature] Enable/disable individual errors/warnings

[mirosval]

At the risk of sounding like a broken record (I've posted a variation of this problem and solution already #5339 and #3369) I decided to ask again here, because I keep running into this issue.

New context (in addition to the 2 mentioned above)

I'm running dbt on CI. I would like to use the --select state:modified state:new --state ./master selector to run and test changed files. Sometimes when I do this, I will get warnings that should really be errors. To solve this I'm doing something like dbt --warn-error list --select state:modified+ state:new --state ./master. But then this fails if there are no modified or new files which I don't want on CI (I do want that when running on Airflow).

Workarounds

I came up with a workaround (which using dbt list --warn-error already is a workaround, because I can't run dbt test --warn-error as mentioned in #3369) that is to first run dbt list --quiet --select state:modifed+ state:new and then gate all further CI steps based on output of that (including a dummy dbt --warn-error list --select $(dbt list --quiet --select state:modified+ state:new)).

Another workaround kindly suggested in #5339 is to use the structured logging output, which apart from being very inconvenient to use, doesn't specifically address the The selection criterion 'state:modified+' does not match any nodes as the code it comes with is Z046, which just is a general warning, so I would have to further parse the output message.

Proposal

But this all feels like it could be solved by having flags for all common problems as settable to either warning or error. On CI I'd like the no-node-selected be a warning, while on Airflow it should be an error. This is similar to how compilers usually do this (-Werror=<name-of-error>)

I'm sorry if this is already getting annoying, but please let me know if I could contribute a solution.

[RobMcZag]

Hi, I love the new dbt Cloud UI that even in Job results highlights Warnings and Errors, but to make the most of it we should be able to keep the jobs as green as possible to notice any change.

I have a warning that gets in all steps of my jobs in one project:

09:03:16  [WARNING]: Configuration paths exist in your dbt_project.yml file which do not apply to any resources.
There are 1 unused configuration paths:
- seeds.precision_forestry.seed_load_ts

The problem is this is a fake entry that I need to be able to reuse the same definition over and over with a decent name using YAML anchors:

    seed_load_ts: &load_ts        # "fake" entry ...
      +column_types:
        loadtime: timestamp
...

It would be good for me to be able to ignore this warning, possibly from this YAML file (or anywhere).
The goal is that the build should always be green without false positives, so that each hit (warning or error) should be investigated.

[jtcohen6]

@mirosval Sorry for the delay following up here - almost a year later!

In v1.4 (released in January), we created a more rigorous taxonomy of warning-level events, and we added --warn-error-options allowing users to control exactly which warnings are promoted to errors:

The WARN_ERROR_OPTIONS config gives you more granular control over exactly which types of warnings are treated as errors. Warnings that should be treated as errors can be specified through include and/or exclude parameters. Warning names can be found in dbt-core's types.py file, where each class name that inherits from WarnLevel corresponds to a warning name (e.g. AdapterDeprecationWarning, NoNodesForSelectionCriteria).

See https://docs.getdbt.com/reference/global-configs/warnings for more details and examples.

@RobMcZag This doesn't quite give you the ability to fully disable warning messages — but by setting this config to promote the warnings you truly care about, it might give you the peace of mind to take the rest as suggestions, rather than action items.

[rob-apella]

@jtcohen6 thanks! anything in the pipeline for the future re. actually disabling certain warnings? I have the same use case as Rob

[dbeatty10]

@rob-apella we don't have anything in the pipeline currently for being able disable certain warnings. But if we did, it would be an option to address #8169 as well.