All flags in file hack/verify-flags/known-flags.txt should contain
character -, this change check this to prevent adding useless flags
to known-flags.txt
Automatic merge from submit-queue
s/positive/negative/ in the error message
I think we meant to imply that "if the error isn't real" then update the
exceptions file - which to me means "false negative", ie. false failure.
Signed-off-by: Doug Davis <dug@us.ibm.com>
I think we meant to imply that "if the error isn't real" then update the
exceptions file- which to me means "false negative", ie. false failure.
Signed-off-by: Doug Davis <dug@us.ibm.com>
We know there are some flags (declared with an _) which we wish to
ignore. These flags are used by container definitions, e2e, etc. By
explicitly ignoring those flags we can cut the amount of noise in the
whitelist.
Check to make sure there is not an alphanumeric character immeditely
before or after the 'flag'. It there is an alphanumeric character then
this is obviously not actually the flag we care about. For example if
the project declares a flag "valid-name" but the regex finds something
like "invalid_name" we should not match. Clearly this "invalid_name" is
not actually a wrong usage of the "valid-name" flag.
This works by defining two 'static' lists in hack. The first is the list
of all flags in the project which use a `-` or an `_` in their name. All
files being processed by verify-flags-underscore.py (or all files in the
repo if no filename arguments are given) will be searched for flag
declaration using a simple regex. Its not super smart. If a flag is
found which is not in the static list it will complain/reject the commit
until a human adds it to the list. If we do not keep a static list of
flags it takes >.2 seconds to find them 'all' at runtime. Since this is
run in pre-commit saving every part of a second helps.
After it finds all of the flags it runs all of the arguments (or all
files in repo if no arguments) looking for usage of those flags which
includes an `_`. There are lots of places where these are false
positives. For example we have a flag named oom-adj-score but the kernel
calls it oom_adj_score. To handle this we keep a second 'whitelist' of
lines which are allowed to use these flag names with an `_`.
Running the entire git repo looking for flags in every golang file and
looking in every single file for bad usage takes about 8.75 seconds.
Running it in the precommit hook where we only check things that changed
takes about .06 seconds.
Cao Shufeng