This allows us to start building real dependencies into Makefile.
Leave old hack/* scripts in place but advise to use 'make'. There are a few
rules that call things like 'go run' or 'build/*' that I left as-is for now.
- Add Godeps/LICENSES.md
- Add verify-godep-licenses to verify that Godeps/LICENSES.md is up to date
- Trigger verify-godep-licenses in the pre-commit hook only if the Godeps dir has changed
- Exclude verify-godep-licenses in verify-all
- Add verify-godep-licenses to make verify (used by travis)
- Add verify-godep-licenses to shippable
- Update dev docs to mention update-godep-licenses
Some programs like the boilerplate or the flag checker will check the
whole repo if they aren't given a specific set of files to test. If you
use `git commit --amend` to change commit messages you will be calling
these functions with no args, and thus it take a lot longer to commit no
changes than it does to actually commit changes!
It is a pretty slow test (it downloads fresh) all of kube's Godeps, so only
run it when needed in pre-commit hook.
This also means that random changes to other non-kube repositories could
cause travis/shippable to just randomly stop working for all PRs which touch
Godeps after that moment (even though no changes have been made to Godeps by
us). Examples would be things like other repos completely disappearing. Or
even the directory we include disappearing in master in the remote
project (even though the directory may exist at the commit we care
about) This is a bugwin godep, but it is a problem we have seen happen
with kube Godeps.
Although the boilerplate checker was very fast it can be faster. With
this change we can hand the boilerplate a list of files which need to be
checked or give it no files. If given no files it will run all files in
the repo. Before you had to explicitly tell the boiler checker the
'extention' of the the files. In this case we let the checker figure it
out and load the headers as needed.
Doing the whole repo takes about 0.4 seconds. Doing a single go file
takes < .04 seconds.
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.
Right now some of the hack/* tools use `go run` and build almost every
time. There are some which expect you to have already run `go install`.
And in all cases the pre-commit hook, which runs a full build wouldn't
want to do either, since it just built!
This creates a new hack/after-build/ directory and has the scripts which
REQUIRE that the binary already be built. It doesn't test and complain.
It just fails miserably. Users should not be in this directory. Users
should just use hack/verify-* which will just do the build and then call
the "after-build" version. The pre-commit hook or anything which KNOWS
the binaries have been built can use the fast version.
Justin Santa Barbara