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.
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.
It looks like there are places where things were needed for one command
were being just needlessly copied. Which made the files harder to
recognize what mattered and what didn't...
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.
pkg/service:
There were a couple of references here just as a reminder to change the
behavior of findPort. As of v1beta3, TargetPort was always defaulted, so
we could remove findDefaultPort and related tests.
pkg/apiserver:
The tests were using versioned API codecs for some of their encoding
tests. Necessary API types had to be written and registered with the
fake versioned codecs.
pkg/kubectl:
Some tests were converted to current versions where it made sense.
- Updates travis to run karma
- Adds some actual tests
Sample build success: https://travis-ci.org/djvirgen/kubernetes/jobs/61567253
Note: My branch is currently up to date with master but all the Go stuff is failing in Travis. Not sure why Go is failing, but the Karma stuff is running OK. I've also verified that when a Jasmine test fails, Travis will fail the build (see [this build](https://travis-ci.org/djvirgen/kubernetes/jobs/61567666) here).
Integration test often time out because the machine is loaded. Instead of
increasing timeout, this change hopes to address the issue by limiting the
number of tests running simultaneously.
Add a new flag in integration.go to specify the maximum number of concurrent
tests. Set the default in travis and shippable configurations to be 4.
take 30-60s, but a number of them reach the 60s timeout and are
aborted. It seems our Travis (and Shippable?) flakiness is
self-inflicted due to too-short timeouts?
When code coverage is not being collected, just issue a single 'go test'
command, as is already done. Go will internally parallize execution.
When code coverage is being collected, it is necessary to issue separate
'go test' commands for each package, since Go does not support
collecting coverage across packages. Using xargs -P will parallelize
these invocations, however, speeding up test execution.
The number of simultaneous processes to use can be specified with
KUBE_COVERPROCS.
Update Travis config to pass along the number of CPUs to use for running
tests.
* Rewrite a bunch of the hack/ directory with modular reusable bash libraries.
* Have 'build/*' build on 'hack/*'. The stuff in build now just runs hack/* in a docker container.
* Use a docker data container to enable faster incremental builds.
* Standardize output to _output/{local,dockerized}/bin/OS/ARCH/*. This regularized placement makes cross compilation work.
* Move travis specific scripts under hack/travis
With new dockerized incremental builds, I can do a no-op `make quick-release` in ~30s. This is a significant improvement.
