Go 1.4 added the -o flag to the "go test" command as well as support for
the TestMain() function, so we must work around these not existing in
Go 1.3.
The version of readlink on OS X does not have the -f flag - so we'll
just skip canonicalizing the path.
This commit deletes cmd/e2e and updates hack/ginkgo-e2e.sh to use the
'ginkgo' command instead. All logic from cmd/e2e/e2e.go and
test/e2e/driver.go have been combined into the new file
test/e2e/e2e_test.go.
The test tarball now includes a built version of the test/e2e test
binary, which includes all tests under test/e2e. This was accomplished
by updating the build scripts to use 'go test -c' when a target name
ended with '.test', and adding a dependency on test/e2e/e2e.test.
This prebuilt test binary is passed to the Ginkgo runner in
hack/ginkgo-e2e.sh. In a future change, we can add support to run
Ginkgo against the source tree if it is available.
This change is generally intended to have no externally visible changes,
aside from the following caveats:
- The -t/--tests flag has been removed
- Calling cmd/e2e/e2e directly obviously won't work, but that was never
intended to be supported anyway
- If the GINKGO_PARALLEL environment variable is set to y, then ginkgo
will run test specs in parallel. (Currently defaults to n, since some
tests are broken in this mode.)
Additionally, several tests which made poor assumptions about cwd or
used testContext before it had been set have been fixed.
It's just a little bit faster.....
BEFORE:
$ time hack/verify-boilerplate.sh
real 0m9.378s
user 0m3.405s
sys 0m13.906s
AFTER:
$ time hack/verify-boilerplate.sh
real 0m0.181s
user 0m0.114s
sys 0m0.068s
This commit deletes cmd/e2e and updates hack/ginkgo-e2e.sh to use the
'ginkgo' command instead. All logic from cmd/e2e/e2e.go and
test/e2e/driver.go have been combined into the new file
test/e2e/e2e_test.go.
Additionally, several tests which made poor assumptions about cwd or
used testContext before it was set have been fixed.
This change is generally intended to have no externally visible changes,
aside from the following caveats:
- The -t/--tests flag has been removed
- Calling cmd/e2e/e2e directly obviously won't work, but that was never
supported anyway
- If the GINKGO_PARALLEL environment variable is set to y, then ginkgo
will run test specs in parallel. (Currently defaults to n, since some
tests are broken in this mode.)
remove node modules
make new data file for web ui
initial commit of dashboard
switch back to non SSL request
move port splitting to common place; add to node resource location
Signed-off-by: Patrick Reilly <patrick@kismatic.io>
various path fixes
make svg path relative
work around missing mime type
Signed-off-by: Patrick Reilly <patrick@kismatic.io>
fix paths
fix karma path
remove bad protractor test
kubectl get can output a series of objects as a List in versioned
form, but not all API objects are available in the same schema.
Make the act of converting a []runtime.Object to api.List more
robust and add a test to verify its behavior in Get.
Makes it easier for client code to output unified objects.
$ hack/parallel-e2e.sh
Usage: hack/parallel-e2e.sh <number of clusters> [options to hack/e2e.go]
Output is logged to _output/e2e/<prefix>. Test failures are aggregated
by slurping the junit results from the parallelized output and
summarized at the end of the run.
Right now, our doc generation scripts notice if you make changes and
don't regen docs, don't include new docs, etc. But they miss it if your
changes should have REMOVED a doc. Both kubectl-apiversion and
kubectl-clusterinfo should have been removed, but weren't.
This patch starts tracking all generated doc files and will cause
problems if files should be removed and aren't.
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.
This seems to be more trouble than its worth, and much of
the remaining build time (except the push itself). We can
cache the cross-build/golang images between builds - it's
not going to kill us, and it'll save the occasional weird
flake of not finding an image when it tries to rm one of
these.
Allows exposing new resource types to be exposed (OpenShift deployment
controllers, copying services, and other resources that will have
pod label selectors).
Also fixed a bug where the selector wasn't exposed because of parameter
defaulting.
Will allow xarg behavior to fetch resources across multiple types.
Changes 'create', 'get', 'update', 'stop', and 'delete' to output
<resourceType>/<name>.
We allow cgo when available since some of our server components (mainly
Kubelet) rely on it. The current driving factor for the static binaries
was building Docker images from scratch. We will instead use images
built from small busybox bases.
Fixes#5517
It includes many of the server components which we only expect to be
able to build in the server target architectures, but it is included in
the client build targets.
A conformance test is a test you run against a cluster that is already
set up. We would use it to test a hosted kubernetes service to make
sure that it meets a bar for quality. Also, a getting-started-guide
author, who has not implemented a complete set of cluster/...
scripts (that is, the getting-started-guide has some non-automated steps)
can use this to see which e2e tests pass on a cluster.
To be done in future PRs:
- disable tests which can't possibly run in a conformance test
because they require things like cluster ssh.
- document that when we accept a getting-started-guide, that
people should run the conformance test against their cluster
(unless they already have cluster/... scripts.
I ran this against a GCE cluster and 22 tests passed.
After change test waits until pods come up and frotend starts serving content,
then adds entry to guestbook and verify if operation succeed
This fixes#3693
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.
During the kubelet's /healthz responce check to see if the
hostname used by the master matches the hostname the kubelet
knows itself by. If not fail the health check.
Signed-off-by: Sami Wagiaalla <swagiaal@redhat.com>
`hack/test-cmd.sh` contains a list of `kubectl` commands to test.
However, the effect of the execution of those commands was not systematically
checked. As a consequence, it was possible to break a command without breaking
those tests.
This commit surrounds every single `kubectl` command with assertions on
pre and post condition.
e2e auth breakage it caused. The fix is to not set project/zone/kube_master
to the empty string partway through the script, which I should have
realized was a bad idea in the first place.
The Go coverage tool does not currently support recording a coverage
data profile across packages, so we must manually combine these coverage
profiles and use it to produce an HTML report when KUBE_COVER is
nonempty. The exact value of KUBE_COVER is now ignored; KUBE_COVERMODE
can be used to set the coverage mode from the default of "atomic".
Additionally, if KUBE_GOVERALLS_BIN is set, hack/test-go.sh will attempt
to report coverage results to Coveralls.io. This is intended to be used
with the Travis build.
Since Jenkins has hopefully been set up properly to read test failures
from junit*.xml files, only exit with a nonzero status when there are
infrastructure failures. If there are only test failures, the nonzero
exit status will be ignored.
Also, disable Ginkgo's colors to make the Jenkin console logs more
readable.
For now, keep the finishRunning() wrapper but use a straight cmd.Run()
call instead of the convoluted goroutine trying to catch signals.
It turns out that Unix process group handling is enough to interrupt
pending processes when stopping the run with something like a Ctrl+C
which should be enough.
Tested:
- Full e2e run with hack/e2e-test.sh, two tests failed but looks like
they've been failing before this change.
- Started a hack/e2e.go -v -build and interrupted it with Ctrl+C,
confirmed that build-release.sh was killed in the process.
This does away with the giant dump from cobra for kubectl and instead
generates md files which contain similar information, but one per verb.
This might work well as part of the cobra project, instead of doing it
in kube, but this gets us nice, linked, documentation right now. If
people like it, I will try to get something similar into cobra.
Try to cleanup if there is a failure in script at any point.
Handle undefined vars in cleanup.
Wait longer for apiserver.
Exit if apiserver doesn't come up.
And actually, make it more better: Go ahead and tear down the cluster
even when tests fail, but (hopefully) relay the test exit status
correctly. This fails if there's a double error (if -down *also*
fails, we'll fail due to errexit), but either way is a build failure,
and this means that the teardown of a test failure build isn't getting
charged to the next run.
Export the KUBE_CONFIG_FILE environment variable pointing to the test
output when calling cluster/kubectl.sh directly.
Tested by running:
$ go run ./hack/e2e.go -v -ctl='version --match-server-version=false'
This gets rid of bashWrap() and of running bash -s passing it a script
on stdin. Also get rid of most of the runBash*() helpers.
In particular, `go run hack/e2e.go -build` will now work when it needs
to ask whether it is OK to download a large docker image, it used to
fail since stdin was not available for the bash script using the `read`
command.
Tested by running a full `hack/e2e-test.sh` run including the build
stage without the docker image loaded, which used to fail before this
change.
Before we get too many suites baked, I want to get spec randomization
in, just so no one accidentally thinks things flow from top to bottom.
The random seed is printed with every run:
Random Seed: 1423194521 - Will randomize all specs
and can be reproduced using --ginkgo.seed
* Add a test/e2e/shell.go that slurps up everything in hack/e2e-suite
and runs it as a bash test, borrowing all the code from hack/e2e.go.
* Rip out all the crap in hack/e2e.go that deal with multiple tests
* Move hack/e2e-suite/goe2e.sh to hack/ginkgo-e2e.sh so that it
doesn't get slurped up.
Simply incorporate some of the boilerplate from hack/e2e.go into the
scripts in hack/e2e-suite.
Use environment variables with default values to allow overrides in
kubectl command line and to use a versioned package root.
Tested:
- Ran `go run hack/e2e.go -test` on a test cluster.
- Ran the test cases individually.
- Ran hack/e2e-suite/goe2e.sh -t Pods to confirm it takes arguments.
- Also fixed cluster/test-network.sh (which should be more and more irrelevant.)
This is another step in removing external dependencies of the Go e2e tests.
Remove references to this file on list of files required to run e2e tests.
Also use an unique name for the pod, so that failure in cleanup of a
previous run should not break a new run with a name conflict.
Tested by running cmd/e2e -t TestPodUpdate against an API server in GCE.
This will increase build times on Jenkins, but should make the build
times consistent and make them pull from sources every time versus
leftover artifacts. Also upping timeout. (Try to address recent
some aborted builds.)
This is another step in removing external dependencies of the Go e2e tests.
Also remove other references to this file.
Tested by running cmd/e2e -t TestKubeletSendsEvent against an API server in GCE.
Use the E2E_REPORT_DIR global environment variable to define the
location where the JUnit XML reports should be saved.
Modify the Jenkins e2e.sh script to export that variable pointing to the
top of the Jenkins build tree.
Tested by running `E2E_REPORT_DIR=${PWD}/.. hack/e2e-test.sh` and
confirmed ../junit.xml was generated and looked good.
Removed auth for Grafana to facilitate usage via service proxy on the api-server.
Added a grafana service
Removed elasticsearch dependency for monitoring - faster startup times.
This was staring at me yesterday, and I even commented that "huh,
there's got to be something wrong with the firewall rules, but then
job/kubernetes-e2e-gce/1002/tapResults/ made it obvious: If you have
two e2e jobs running at the same time in the same project (hint:
Jenkins does), they'll race with each other, since resource names are
project scoped.
And a config description. This doesn't yet have much - first want to
make sure I can do the build job. Next I'll submit the e2e script with
its twiddles and switch those over. (After going to 3 e2es, I think
it's finally time for version control.)
This exposes the proper v1beta3 API endpoint when the user specifies
the --runtime_config=api/v1beta3 argument to the apiserver. v1beta3
is still considered experimental and subject to change.
--runtime_config is a map of string keys and values, that can be
specified by providing
--runtime_config=a=b,b=c,d,e
Only the key must be specified, the value can be omitted.
Enables v1beta3 in hack/local-up-cluster.sh and hack/test-cmd.sh
Scheduler uses Reflector from pkg/client/cache.
It defines some helper classes.
I'd like to use those helpers with pkg/client/cache
in kube-proxy and kubelet too.
There are quite a few 'composite literal uses unkeyed fields' errors that I have kept out of this patch.
And there's a couple where vet just seems confused. These are the easiest ones.
What I really want is
https://github.com/GoogleCloudPlatform/kubernetes/issues/2953, but
haven't had a chance to code that yet. Maybe it's time. (Then I'd
remove the provider-specific test and just say "is it > 0.7.2, or does
it claim to be capable of something from the future?" The latter
covers the HEAD server case .. though just bumping the server version
immediately after release might also accomplish that, too.)
After this DNS is resolvable from the host, if the DNS server is targetted
explicitly. This does NOT add the cluster DNS to the host's resolv.conf. That
is a larger problem, with distro-specific tie-ins and circular deps.
Add test artifacts to the build. This lets you do:
tar -xzf kubernetes.tar.gz
tar -xzf kubernetes-test.tar.gz
cd kubernetes
go run ./hack/e2e.go -up -test -down
without having a git checkout.
by adding support for testing official release versions and writing a
simple script to first bring up and test the old version before
upgrading it and testing it again. Related to supporting in-place
upgrades of masters (#2524).
Make each test available for execution --times times. Acts like a
multi-deck shoe. (Otherwise this is easily scriptable outside the
e2e.go command).
Useful for "I want to walk away for a few hours leaving some end-to-ends
running", until we have more stress tests. Also useful for detecting
flakes.
Reporting is changed to break out Passed, Flaky and Failed. I chose to
keep all three lines even if --times isn't on, just for consistency in
scraping. Similarly, it always outputs the counts now. A report looks
like:
2014/12/09 07:31:21 Passed tests: goe2e.sh[100/100] guestbook.sh[100/100] private.sh[100/100] services.sh[100/100]
2014/12/09 07:31:21 Flaky tests: basic.sh[99/100] certs.sh[99/100] monitoring.sh[98/100] pd.sh[98/100] update.sh[98/100]
2014/12/09 07:31:21 Failed tests:
2014/12/09 07:31:21 8 test(s) failed.
Replaces the client public interface but leaves old references to "minions"
for a later refactor. Selects the path "nodes" for v1beta3 and "minions"
for older versions.
Currently, we run the e2e tests in whatever order readdir happens to
return, which is random on some filesystems, name sorted on others,
create order on others, etc. Eventually, we may want to be
automatically hermetic between e2e tests (especially as we introduce
more resource destructive tests), but until then, it would be useful
if we permute the test order randomly between runs to ensure that
developers don't accidentally rely on a particular order. This
introduces a form of forced hermeticism, since improper state cleanup
from one test may not perturb a given test, but there's probably *a*
test in the suite that the order will perturb, so the RNG will find
that order eventually.
Adds logging of the generated seed, and an --orderseed argument that
can be used to re-run in the same order. Also sorts the pass/fail list
now for easier human reading.
Minor usability nuisance: If you run:
go run hack/e2e.go -v -test
.. and you don't happen to have an up e2e cluster, it should fail
fast, rather than chugging through every test and having them fall
over.
This commit brings two main changes, notably:
Two new options that can be set as environment variables
- DOCKER_OPTS: any arbitrary set of docker options. Example: --tlsverify
- DOCKER_NATIVE: This forces the use of the native docker available.
This is most useful if you're on OS X and do not want
to use boot2docker.
Now uses 'docker cp' instead of tar piping to transfer files. This
currently must be done by copying the binaries off of the docker volume
and into a local filesystem (/tmp) before a docker cp is done. This
workaround will no longer be necessary after bug fix
https://github.com/docker/docker/pull/8509 makes it into stable.
This was necessary because the tar | tar method was creating corrupted
archives on OS X even with the < /dev/null workaround.
This change refactors the way Kubelet's DockerPuller handles the docker config credentials to utilize a new credentialprovider library.
The credentialprovider library is based on several of the files from the Kubelet's dockertools directory, but supports a new pluggable model for retrieving a .dockercfg-compatible JSON blob with credentials.
With this change, the Kubelet will lazily ask for the docker config from a set of DockerConfigProvider extensions each time it needs a credential.
This change provides common implementations of DockerConfigProvider for:
- "Default": load .dockercfg from disk
- "Caching": wraps another provider in a cache that expires after a pre-specified lifetime.
GCP-only:
- "google-dockercfg": reads a .dockercfg from a GCE instance's metadata
- "google-dockercfg-url": reads a .dockercfg from a URL specified in a GCE instance's metadata.
- "google-container-registry": reads an access token from GCE metadata into a password field.
Also fix up cert generation. It was failing during the first salt highstate when trying to chown the certs as the apiserver user didn't exist yet. Fix this by creating a 'kube-cert' group and chgrping the files to that. Then make the apiserver a member of that group.
Fixes#2365Fixes#2368
apiserver becomes kube-apiserver
controller-manager -> kube-controller-manager
scheduler and proxy similarly.
Only thing I promise is that right now hack/build-go.sh and
build/release.sh exit with 0. That's it. Who knows if any of this
actually works....
It's actually used unset a couple of lines after this patch, but this
just resolves it in one place instead of calling
$(kube::golang::host_platform) twice.
Because of Fedora's crazy packaging guidelines, go install basically
isn't allowed. So allow us to use go build instead of go install.
test-integration also needs to accept the flag to be able to pass it
along to the build function.
* 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.
test-cmd runs a 127.0.0.1 version of the apiservers, but does not
set --public_address_override, which means it can fail on some systems
(like Macs) which don't expose a bindable external port by default.
Since reachability is not necessary for test-cmd.sh today, set
public_address_override to 127.0.0.1
Added basic interface for authorizer implementations.
Added default "authorize everything" and "authorize nothing
implementations.
Added authorization check immediately after authentication check.
Added an integration test of authorization at the HTTP level of
abstraction.
Proper quoting, error checks, use $KUBE_* variables when applicable, trap to do
cleanup on all errors, call cleanup explicitly on successful exit.
Tested:
- Ran it manually to completion, test run successful.
- Interrupted it during the run, checked that $? was non-zero, etcd was killed.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This doesn't fix anything broken. But we have config-go which exports
KUBE_REPO_ROOT and KUBE_TARGET. Using those means the test scripts can
be more easily moved around the repo and still work. Especially in
hack/test-integration.sh where we use hack/build-go.sh which is going
to use KUBE_TARGET to place the binary, then we use a different method
to find/execute the binary...
If this is set, and it normally shouldn't be, the config file will not
add the in tree Godeps to the GOPATH. So all of them must be solved by
the KUBE_EXTRA_GOPATH
This fixes `hack/test-go.sh pkg/apiserver -test.run=<a_specific_test_name>`
which was broken by PR #1116.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
add usage
verify flag value for -i is numeric
allow multiple targets on the command line
actually capture coverage output
fix lingering GOFLAGS undef issue
fix issue with -i not working at all: ((x++)) returns 1 when x is 0, which is
incompatible with "set -e"
Set the values of major and minor version based on the output of the
`git describe` command, which uses annotated tags as source of
versioning information.
Minor will get a "+" appended whenever the annotated tag does not match
the tree exactly (including when the tree is dirty.) So that only
official releases will have a "bare" minor version, all others will have
a "+" to indicate the binaries contain changes from the released version
in minor.
(This is similar to how versions of development builds of the Linux
kernel work.)
Tested:
- With no annotated tags:
$ hack/build-go.sh
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"0", Minor:"1+", GitVersion:"v0.1+", GitCommit:"7d29873bdee87efacaace30ab3602297cacf1b4f", GitTreeState:"clean"}
- Tagging current version on a clean git tree:
$ git tag -a -m 'Test tag v2.3' v2.3
$ hack/build-go.sh
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"2", Minor:"3", GitVersion:"v2.3", GitCommit:"7d29873bdee87efacaace30ab3602297cacf1b4f", GitTreeState:"clean"}
- Tagging current version on a dirty git tree:
$ git tag -a -m 'Test tag v2.3' v2.3
$ touch test.txt # this is enough to mark the tree as dirty
$ hack/build-go.sh
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"2", Minor:"3+", GitVersion:"v2.3-dirty", GitCommit:"7d29873bdee87efacaace30ab3602297cacf1b4f", GitTreeState:"dirty"}
- Tagging a previous version on a clean tree:
$ git tag -a -m 'Test tag v2.3' v2.3 HEAD~5
$ hack/build-go.sh
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"2", Minor:"3+", GitVersion:"v2.3-6-g7d29873bdee87e", GitCommit:"7d29873bdee87efacaace30ab3602297cacf1b4f", GitTreeState:"clean"}
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Ensure the output of `git describe` will include the `-dirty` suffix
when building on a tree with modified files in it.
Tested:
- ...
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Run the snippet that creates the output/go/ tree in a subshell.
Tested:
- Built it with hack/build-go.sh
- Ran release/build-release.sh successfully.
- Moved away the git tree to confirm no regression in PR #1073.
- Sourced hack/config-go.sh in the shell, confirmed no variable or
function other than the expected ones leaked into the environment.
- Used `git grep` to confirm the no longer exported variables were
not in use by any script other than config-go.sh.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
The old method (using `readlink`) was convoluted and not portable. We
can achieve the same result using only bash builtins.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Add a section for environment variables in config-go.sh. Document the
three public environment variables defined by this script. Make sure the
variables get exported so that they can be used by commands spawned by a
shell that sourced the config script.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This is caused by bash thinking that an empty array is the same as an
undefined variable and `set -o nounset` treating that as an error.
Fix that by using an empty string as the default for the expansion.
Fixes PR #1069 (6e25f60288).
Tested:
- Before this patch:
$ mv .git .gitbackup
$ hack/build-go.sh
/home/filbranden/devel/kubernetes/hack/config-go.sh: line 55: ldflags[*]: unbound variable
- After this patch:
$ mv .git .gitbackup
$ rm -rf output/
$ hack/build-go.sh
$ output/go/bin/kubelet -version
Kubernetes version 0.1+, build (unknown)
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This replaces the gitcommit() shell function with kube::version_ldflags()
which prepares a string suitable for Go's -ldflags parameter that fills
in the git version fields in pkg/version/base.go.
The gitCommit is now a full 40-character SHA1, the gitVersion will be
filled from `git describe` output (which will only be available once we
have annotated git tags) and gitTreeState will be filled with either
"clean" or "dirty" depending on the tree status at the time of the
build.
Use a kube:: "namespace" (there's really no such a thing in shell, but
the illusion still makes it nice) in order to make this nice to import
into existing shell scripts or on a shell session. (In the future, I'm
planning to introduce more functions and convert some of the top-level
commands into other kube::* shell functions.)
There's a difference now that -version will report a full SHA1, this
will be improved in a follow up change which will improve the Go code
for -version handling to give a more meaningful string that should be
enough to identify the origin of the binary in git.
Tested:
- Built it and checked output of -version:
$ hack/build-go.sh
$ output/go/bin/kubelet -version
Kubernetes version 0.1+, build 3ff7ee4b8c843c7767cd856fbf7d3027cd5410e6
- Ran the release script and checked output of the common.sls file:
$ release/build-release.sh TESTINSTANCE
$ cat output/release/master-release/src/saltbase/pillar/common.sls
instance_prefix: TESTINSTANCE-minion
go_opt: -ldflags '-X github.com/GoogleCloudPlatform/kubernetes/pkg/version.gitCommit 3ff7ee4b8c843c7767cd856fbf7d3027cd5410e6 -X github.com/GoogleCloudPlatform/kubernetes/pkg/version.gitTreeState clean'
- Successful run of hack/e2e-test.sh end-to-end tests.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Instead of using `godep path`, we can simply set the GOPATH directly to
point to the Godeps/_workspace. We can still use `godep` to manage the
dependencies on the Godeps/ tree, but we don't need to have it available
for straight builds from git.
v2: Rebased and moved to inside kube::setup_go_environment() function.
Tested:
- Built it without godep in $PATH:
$ hack/build-go.sh
- Ran unit tests without godep in $PATH:
$ hack/test-go.sh
- Retested after rebase.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This way hack/config-go.sh can be used in environments where Go is not
available, such as running release/build-release.sh for Vagrant.
(The intention is to make config-go.sh a general library of helper
functions and import it from most other shell scripts.)
Fixes Issue #1057.
Tested:
- Built it and made sure it works.
$ hack/build-go.sh
$ output/go/bin/kubelet -version
Kubernetes version 0.1+, build 0766e7a411c7-dirty
- Ran unit tests.
$ hack/test-go.sh
ok github.com/GoogleCloudPlatform/kubernetes/examples 1.105s coverage: 0.0% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/api 6.188s coverage: 86.1% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors 1.015s coverage: 81.8% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver 1.806s coverage: 85.1% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/client 1.211s coverage: 67.2% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/client/cache 1.115s coverage: 95.5% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/cloudprovider/gce 1.052s coverage: 7.3% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/cloudprovider/vagrant 1.045s coverage: 76.8% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/constraint 1.038s coverage: 100.0% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/controller 1.559s coverage: 78.8% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/conversion 3.440s coverage: 72.4% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/election 1.034s coverage: 71.4% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/health 1.043s coverage: 94.5% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/healthz 1.034s coverage: 100.0% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/httplog 1.027s coverage: 82.4% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/kubecfg 6.081s coverage: 58.5% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet 1.400s coverage: 72.2% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet/config 1.139s coverage: 90.1% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/labels 1.041s coverage: 98.7% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/master 1.033s coverage: 33.3% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/proxy 1.095s coverage: 86.5% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/proxy/config 1.038s coverage: 39.2% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/registry/binding 1.046s coverage: 100.0% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/registry/controller 1.039s coverage: 43.6% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/registry/endpoint 1.029s coverage: 25.0% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/registry/etcd 1.110s coverage: 79.5% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/registry/minion 1.048s coverage: 72.3% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/registry/pod 1.052s coverage: 62.1% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/registry/service 1.054s coverage: 80.0% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/scheduler 1.030s coverage: 90.4% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/service 1.363s coverage: 83.8% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/tools 1.136s coverage: 81.9% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/util 1.049s coverage: 83.9% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/util/config 1.036s coverage: 92.9% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/util/wait 1.029s coverage: 86.7% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/volume 1.032s coverage: 83.3% of statements
ok github.com/GoogleCloudPlatform/kubernetes/pkg/watch 1.040s coverage: 100.0% of statements
ok github.com/GoogleCloudPlatform/kubernetes/plugin/pkg/scheduler 1.026s coverage: 90.9% of statements
ok github.com/GoogleCloudPlatform/kubernetes/plugin/pkg/scheduler/factory 1.075s coverage: 85.4% of statements
? github.com/GoogleCloudPlatform/kubernetes/test/integration [no test files]
- Ran release/build-release.sh without go or godep in my $PATH.
$ PATH=...
$ which go
$ which godep
$ release/build-release.sh MYTEST
Building release tree
~/devel/kubernetes ~/devel/kubernetes
~/devel/kubernetes
Packaging release
$ cat output/release/master-release/src/saltbase/pillar/common.sls
instance_prefix: MYTEST-minion
go_opt: -ldflags "-X
github.com/GoogleCloudPlatform/kubernetes/pkg/version.gitCommit '0766e7a411c7-dirty'"
$ find output/release/master-release/ | wc -l
598
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Now it is possible to push these variables through ldflags:
- gitMajor
- gitMinor
- gitVersion (from latest annotated tag, output of git describe)
- gitCommit (renamed commitFromGit, intended to have the full sha1)
- gitTreeState (either "clean" or "dirty")
These are spawned into its separate source file, since they are meant to
be updated separately when a new version is released.
Also use the notation vX.Y+ for when git information is not present.
(This is consistent with the kernel build, e.g. Linux 3.15+ means its
version is >= 3.15 and < 3.16.)
v2: Added comments to the individual fields in pkg/version/base.go
Tested:
- Built it and checked the -version output:
$ hack/build-go.sh
$ output/go/bin/kubelet -version
Kubernetes version 0.1+, build c328679ef8aa
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Previously it would only print a version when the tree was dirty. Fix it
so that it will also print one on a clean tree.
Tested:
- Built it from a committed tree:
$ hack/build-go.sh
$ output/go/bin/kubelet -version
Kubernetes version 0.1, build a091590dd10c
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Currently hack/test-go.sh runs in serial in independent executions of
go test. By running all tests at once, we get parallel execution.
However, we cannot use -coverprofile with this mode, which seems worthwhile.
On a 4-core mac, runs tests in 15s that ran in 80s before. Tested on F20 and
OSX Mavericks.
Fix quoting so that it works with arbitrary path names (e.g. containing
spaces.) Make hack/config-go.sh non-executable since it is meant for
sourcing and not as a standalone.
Tested:
- Checked out the tree to a directory with spaces, called the
build script from outside the tree, confirmed it worked as expected.
- Confirmed binaries work by running them with -version.
- Ran hack/build-go.sh cmd/kubecfg and confirmed only kubecfg was built.
- Ran hack/build-go.sh cmd/integration and confirmed it was built.
- Checked it out on a Mac and confirmed that the build script works.
- Confirmed that hack/test-go.sh and hack/test-cmd.sh work.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Detect whether the tree is dirty and append a "-dirty" indication to the
git commit (common practice with other repos, e.g. kernel, docker.)
Properly handle the case where a git tree is not found (e.g. building
from archive.)
In the sed expression, look for the variable to be updated
(commitFromGit) instead of hardcoding a line number.
Tested:
- Built from a dirty tree:
$ output/go/bin/kubelet -version
Kubernetes version 0.1, build 2d784c684c75-dirty
- Built from a clean tree:
$ output/go/bin/kubelet -version
Kubernetes version 0.1, build 505f23a31172
- Built from an archive:
$ hack/build-go.sh
WARNING: unable to find git commit, falling back to commitFromGit = `(none)`
$ output/go/bin/kubelet -version
Kubernetes version 0.1, build (none)
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Tested: Passed -version argument to kubelet (and all other binaries):
$ output/go/bin/kubecfg -version
Kubernetes version 0.1, build 6454a541fd56
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
In Go it's much more efficient to build several commands in the same
`go build` because the build has to load most of the dependency tree
each time. Roughly 50% on my machine:
Together (go1.2 on OS X):
real 0m4.049s
user 0m8.387s
sys 0m2.766s
Separate:
real 0m13.392s
user 0m12.420s
sys 0m6.882s
Pass arguments after the package directly to go test
hack/test-go.sh pkg/util -v -test.run=TestNewStringSet
And also allow global flags
hack/test-go.sh "" -v
Fixed up some scripts to be more robust. Changed the e2e test setup to use g1-small instances. Fixed up documentation to reflect the new script locations. Disabled the "curl | bash" cluster launch as it hasn't been well tested and doesn't include the cloudcfg tool yet.
