SaltStack 2014.7.1 double-quotes tar filenames which means the file can't
be found. A workaround is not to specify tar_options, which hits a different
code path. But that breaks the older version of SaltStack that GCE is locked
to, hence we need the version conditional (thanks @jbeda)
Fixes issue #3932
client.Config describes how to make a client connection to a server
for HTTP traffic, but for connection upgrade scenarios cannot be
used because the underlying http.Transport object can't allow the
connection to be hijacked. Reorganize the TLS and connection wrapper
methods so that a sophisticated client can do:
cfg := &client.Config{...} // from somewhere
tlsConfig, _ := client.TLSConfigFor(cfg)
_ := conn.Dial(...)
rt := MyRoundTripper() // some func that implements grabbing requests
wrapper, _ := client.HTTPWrappersFor(cfg)
req := &http.Request{}
req.Header.Set("Connection-Upgrade", ...)
_, := wrapper.RoundTrip(req)
// rt has been invoked with a fully formed Req with auth
rt.Req.Write(conn)
// read response for upgrade
It would be good to have utility function that does more of this,
but mostly enabling the HTTP2/SPDY client exec function right now.
Support namespacing in cache.Store by framing the interface functions
around interface{} and providing a key function to each Store implementation.
Implementation of a fix for #2294.
Avoid importing the YAML files from the examples/ tree, instead just
define the api.Pod structs in the Go source code.
Tested by running the TestLivenessHttp and TestLivenessExec tests
against a test cluster.
Use the --ginkgo.focus flag which accepts a regexp to define which tests
should be run. Create a regexp matching a full word that is exactly one
of the test names passed as -t parameters.
Tested with cmd/e2e -t TestLivenessHttp -t TestLivenessExec, confirmed
that 2 tests were executed and 9 were skipped.
Instead of forcing the NoColor flag to on at runtime, make it default to
being on in a way that it's still possible to override it by passing e2e
the --ginkgo.noColor=false command-line flag.
Tested by running the tests with and without the flag and confirming
that both worked as expected.
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.
This is the start of an uber-binary that can morph into any server. Eventually we'll want this to be able to launch multiple servers from a single command line.
Use ginkgo's native support for JUnit in order to generate the XML file.
This is a first step in better integration of our e2e tests with
Jenkins. In order to improve the logged information, we will probably
need to have more native ginkgo tests but this step allows us to see
what Jenkins can already do with this information and what we need to
tweak to improve it.
Tested by running the full e2e tests and inspecting the contents of
junit.xml on the top of the tree.
Textual output is still generated on the console to keep the current
goe2e.sh logs available until the full conversion of our Jenkins
instance to use the JUnit XML is completed.
In order to adopt ginkgo incrementally, let's start by replacing
test/e2e/driver.go with a call to ginkgo runner and convert each of the
other tests to a small Decscribe() snippet that simply calls the legacy
TestXYZ function.
From this basis we can take further incremental steps by converting
individual tests to native ginkgo format, using Fail() for all failure
cases, using By() for logs, enabling JUnit reports, etc.
Tested:
- cmd/e2e builds and `make check` passes.
- Running _output/bin/.../e2e on an alive cluster works.
- Running the full hack/e2e-test.sh works as expected.
This commit uses `godep` to vendor these libraries into our project.
They are not yet in use but we plan to use them in `test/e2e` in a follow up commit.
