Add ability to only warn about some rules #989
Conversation
|
This looks like a great way to solve some of the issues raised in the 4.3.0 update; thanks so much for this patch! |
lib/ansiblelint/cli.py
Outdated
| @@ -160,7 +162,7 @@ def get_cli_parser() -> argparse.ArgumentParser: | |||
| return parser | |||
|
|
|||
|
|
|||
| def merge_config(file_config, cli_config) -> NamedTuple: | |||
| def merge_config(file_config, cli_config) -> NamedTuple: # noqa: C901 | |||
There was a problem hiding this comment.
I don't have time to do the full review right now but adding complexity is unacceptable.
There was a problem hiding this comment.
That is not real complexity an you know it well, clearly not a reason to block this change. If you know how to avoid scalability issues with merge_config, you are welcomed to refactor it to avoid triggering C901 when newer option are added.
There was a problem hiding this comment.
There is a lot of repetition here. It's not complex, but it is redundant. Maybe the complexity warning could be squashed with a refactor. Something along the lines of (untested)
for field in ('quiet', 'parseable', 'parseable_severity' ... ):
if field in file_config:
setattr(cli_config, field, getattr(cli_config, field) or file_config[field]))
# Repeat again for addition/extendThere was a problem hiding this comment.
@greg-hellings Yes, it may work but it should be a follow-up and C901 should not be used as a ransom for forcing someone to refactor merge_config. This change itself does not add that kind of complexity we want to avoid with C901.
There was a problem hiding this comment.
While the addition of this branch is not complex in itself, it does underscore this method should be refactored as it grows... I am ok with having that on the backlog as added ^.
| @@ -154,8 +165,7 @@ def main() -> int: | |||
| print(formatter.format(match)) | |||
|
|
|||
| if matches: | |||
| hint_about_skips(matches) | |||
| return 2 | |||
| return report_outcome(matches, options=options) | |||
There was a problem hiding this comment.
#992 will gate this so it only shows up when NOT quiet, paresable, or parsable_severity are True. Since again this is adding verbose output, I would expect it not to be enabled for those modes
There was a problem hiding this comment.
It looks like the report_outcome method does the guarding around quiet/parseable itself.
ssbarnea
force-pushed
the
feature/warn
branch
2 times, most recently
from
48d0b05
to
369f021
Compare
| @@ -154,8 +165,7 @@ def main() -> int: | |||
| print(formatter.format(match)) | |||
|
|
|||
| if matches: | |||
| hint_about_skips(matches) | |||
| return 2 | |||
| return report_outcome(matches, options=options) | |||
There was a problem hiding this comment.
It looks like the report_outcome method does the guarding around quiet/parseable itself.
Adds a `warn_list` option were user can add rules that should not affect the outcome of the linting, while they will still be identified. This softer option makes linter easier to adopt while still reminding users about issues they should seek to address.
Adds a
warn_listoption were user can add rules that should notaffect the outcome of the linting, while they will still be identified.
This softer option makes linter easier to adopt while still reminding
users about issues they should seek to address.