Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DO-NOT-MERGE] Add optional E2E test artifact to binary artifacts for openshift #6541

Closed
wants to merge 2 commits into from

Conversation

jayunit100
Copy link
Contributor

Im now testing this on real clusters, will update accordingly. This Implementation takes into account all feedback from the previous implementation, and rolls it into a fresh PR.

This obsoletes #6395

@jayunit100
Copy link
Contributor Author

Fixes #5765

Here is a reimplementation of the e2e build product for openshift.

  • reimplemented so that, by default, no e2e build product is produced (per @liggitt s concerns about performance).
  • includes a sample e2e test which can be borrowed/extended.
  • it manages test dependencies by copying them dynamically.
  • have done some basic re-testing, will do more.

cc @pmorie @timothysc

@jayunit100
Copy link
Contributor Author

Since its disabled by default ; To test this, sudo OS_BUILD_E2E_TEST=true make clean build, And you should see ./_output/local/bin/linux/amd64/e2e.test in the outputs.
Then you can run the tests:
sudo _output/local/bin/linux/amd64/e2e.test --host="https://0.0.0.0:8443" --provider="local" --ginkgo.v=true --ginkgo.focus=Networking --kubeconfig=_output/local/bin/linux/amd64/master/openshift-master.kubeconfig --repo-root=./

@liggitt
Copy link
Contributor

liggitt commented Jan 6, 2016

Should be a separate build target, and should not need sudo to build

@jayunit100
Copy link
Contributor Author

Yes in this case I figured as per your comment, so long as

  • we were capable of building the binary for releases and
  • it was not a product of make build

then that satisfied the requirement of "fast builds by default".

  • good idea to definitely add explicit make target support, but... even so, common.sh is the natural place to build these things it seems. which is called by build-go.sh.
  • Is it a hard requirement, also, to dereference e2e from build-go.sh entirely?

The reason I'm asking, is that build-go.sh by definition builds all go components. , so I am hesitant to completely decouple e2e from build-go.sh.

TL;DR I think we are in agreement, with one question - do we need to eliminate references to e2e from common.sh entirely?

@jayunit100 jayunit100 force-pushed the e2e-bindings-dev-PR branch 4 times, most recently from 93197c2 to 8e7661b Compare January 6, 2016 15:25
@jayunit100
Copy link
Contributor Author

pushed some more updates and rebased/cleaned. testing now. I think this might be close to consensus.

@jayunit100 jayunit100 force-pushed the e2e-bindings-dev-PR branch 2 times, most recently from d24af58 to bb3629b Compare January 6, 2016 15:31
@jayunit100
Copy link
Contributor Author

Okay, here are the new results. Taking into account the above suggestions regarding the Make target.

  • Sudo is not required to build. I was using it unnecessarily in the above example.
  • The Makefile now supports a make e2e goal.
  • The regular build targets now have no reference to the e2e build.

Regular build:

➜  origin git:(e2e-bindings-dev-PR) ✗ make build
hack/build-go.sh
++ Building go targets for darwin/amd64: cmd/openshift cmd/oc
Artifact: github.com/openshift/origin/cmd/openshift
... Building core binary github.com/openshift/origin/cmd/openshift
Artifact: github.com/openshift/origin/cmd/oc
... Building core binary github.com/openshift/origin/cmd/oc
++ Placing binaries
hack/build-go.sh took 19 seconds

And for E2Es:

➜  origin git:(e2e-bindings-dev-PR) ✗ make e2e
hack/build-go.sh test/e2e/e2e.test
++ Building go targets for darwin/amd64: test/e2e/e2e.test
Artifact: github.com/openshift/origin/test/e2e/e2e.test
... Building e2e artifact
++ Placing binaries
hack/build-go.sh took 10 seconds

@@ -3,6 +3,7 @@
# This script provides common script functions for the hacks
# Requires OS_ROOT to be set

set -o nounset
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

duplicate of line 8

Default to false. Formatting fixed, explicit make target.
@jayunit100
Copy link
Contributor Author

Thanks. Ive rebased, squashed, and fixed. I think this is ready for a final look.

@jayunit100
Copy link
Contributor Author

You can also test this locally in DIND, it appears to work, and we can continue using the test-kube-e2e.sh wrapper for consistency, (with just one minor change) to hack/test-kube-e2e.sh.

Delete the KUBE_ROOT stuff, and do

-hack/ginkgo-e2e.sh $@
+.//_output/local/bin/linux/amd64/e2e.test $@

Then, you can do vagrant ssh ; make e2e; hack/test-kube-e2e.sh ; --provider=local --kubeconfig=/tmp/openshift-dind-cluster/openshift/openshift.local.config/master/openshift-master.kubeconfig --ginkgo.focus="30 pods"

import (
. "github.com/onsi/ginkgo"
"k8s.io/kubernetes/test/e2e"
"testing"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, golang style is to separate the stdlib imports from third party with a line break

@jayunit100
Copy link
Contributor Author

fixed the formatting for imports

# Example:
# make e2e
e2e:
hack/build-go.sh test/e2e/e2e.test
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like how this looks

go install "${goflags[@]:+${goflags[@]}}" \
-ldflags "${version_ldflags}" \
"${binaries[@]}"
for artifact in ${binaries[@]}; do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the whole implementation of building the e2e test artifact is different, this probably should be a separate function, maybe even a separate script (build-e2e.sh, modeled after a combination of build-go.sh and test-integration.sh?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a strong case can be made for a wrapped kube e2e, we should do the upstream work to allow wrapping it (putting the guts in a non _test file, and making the _test file a 3-line function we wouldn't mind duplicating

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

making upstream test into a utility is doable, but likely will meet a little pushback.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll say it again, if a strong case can be made for a wrapped kube e2e, we should do the upstream work to allow wrapping it. If a strong case can't be made, we should not wrap it :)

@timothysc
Copy link

cross-ref kubernetes/kubernetes#19476
/cc @jeremyeder

@jeremyeder
Copy link
Contributor

We in performance engineering have a need for a "verify environment" function, and were about to write one. I understand this suite includes conformance tests that could be used for this purpose.

From a correctness and reproducibility standpoint, having access to these conformance tests in OpenShift would increase confidence in our deployments.

@jayunit100 jayunit100 changed the title Add optional E2E test artifact to binary artifacts for openshift [DO-NOT-MERGE] Add optional E2E test artifact to binary artifacts for openshift Jan 13, 2016
@jayunit100
Copy link
Contributor Author

@jayunit100
Copy link
Contributor Author

Closing, upstream alternative is pending. See the original issue for details.

@jayunit100 jayunit100 closed this Jan 16, 2016
@timothysc timothysc mentioned this pull request Feb 2, 2016
85 tasks
@jayunit100
Copy link
Contributor Author

Subsumed by #7049

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants