You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
warn_error_options:
error: # previously called "include", promote to "error"warn: # previously called "exclude", keep as "warn"silence: # NEW: ignore entirely
(We'd retain the old names as well for backwards compatability)
Describe alternatives you've considered
A separate config, WARN_SILENCE, that takes a list. This would be better in the case where a user wants to silence warnings via project flags (version-controlled default for everyone), and also promote specific warnings as errors (via include/exclude) in different runtime environments, without needing to re-specify the silence list every time. While that's slightly more ergonomic, it's also less explicit, and it doesn't feel like a show-stopper.
Only allow users to silence deprecation warnings. I think there's a valid reason to generalize this to all kinds of warnings, e.g. silence ConstraintNotEnforced once for the entire project rather than once per model/constraint in the project.
Remove TestsConfigDeprecation (= give up in advance)
Who will this benefit?
All users of dbt, especially since:
In v1.8, we are renaming tests → to data_tests, for clearer distinction from unit_tests. Tens of thousands of projects will experience the TestsConfigDeprecation. They won't all be able to take action. We should give them a way to silence the deprecation (for now).
Is this your first time submitting a feature request?
Describe the feature
https://docs.getdbt.com/reference/global-configs/warnings
(We'd retain the old names as well for backwards compatability)
Describe alternatives you've considered
WARN_SILENCE
, that takes a list. This would be better in the case where a user wants tosilence
warnings via project flags (version-controlled default for everyone), and also promote specific warnings as errors (viainclude
/exclude
) in different runtime environments, without needing to re-specify thesilence
list every time. While that's slightly more ergonomic, it's also less explicit, and it doesn't feel like a show-stopper.ConstraintNotEnforced
once for the entire project rather than once per model/constraint in the project.TestsConfigDeprecation
(= give up in advance)Who will this benefit?
All users of dbt, especially since:
tests
→ todata_tests
, for clearer distinction fromunit_tests
. Tens of thousands of projects will experience theTestsConfigDeprecation
. They won't all be able to take action. We should give them a way to silence the deprecation (for now).Are you interested in contributing this feature?
:)
Anything else?
Sketched out a start:
Example:
Slack thread with more context
The text was updated successfully, but these errors were encountered: