yetus-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <>
Subject [jira] [Commented] (YETUS-873) Error on unprocessed options/parameters
Date Mon, 13 May 2019 15:53:00 GMT


Sean Busbey commented on YETUS-873:

I found myself wanting to expand the text to expressly say "we'll exit with an error code
in a future release". but then I thought about how I'll need to react to this if I want to
be proactive in updating for it. If I fix up some code, I'll want to know quickly if a regression
happens. which means I'll need to grep all my yetus logs for this message we're outputting.

would it be to much to default to output the current message and exit with an error code,
but add a cli option to skip the exiting part? with the intention of removing said cli option
in our next release?

that way folks who don't want to put off getting strict can fix their errors and be confident
that it'll be noisy if a regression happens. and folks who want to wait a release can add
the flag for now?

> Error on unprocessed options/parameters
> ---------------------------------------
>                 Key: YETUS-873
>                 URL:
>             Project: Yetus
>          Issue Type: New Feature
>          Components: Precommit
>            Reporter: Allen Wittenauer
>            Assignee: Allen Wittenauer
>            Priority: Major
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
> Given how frequently we've been eliminating some parameters lately as we make things
more automatic and/or pushed to be external (e.g., pylintrc vs. CLI options), it is probably
a good idea to start getting stricter on what options are being passed on the CLI.

This message was sent by Atlassian JIRA

View raw message