The level does most of the work. A warning that never blocks anything gets ignored quickly, and then it is noise that trains everyone to skim past real output. If a rule is worth keeping on, it is usually worth failing the build for.
Most warnings arrive inherited, from a shared config rather than a decision. That is the case worth auditing: run your linter and count them, then either promote them so they block or switch them off. Our own config inherits 15 warning-level rules, none of which currently fire, so we made the build fail on any warning at all rather than leave a category of finding that nobody has to act on.
Turn rules on one at a time, with a reason you could explain to whoever hits it next. A config copied from somewhere and understood by nobody gets switched off the first time it is inconvenient, which is worse than never having added it.
Updated August 2026