-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Conversation
86e7c00
to
57bb5b9
Compare
Fixes #5765 Here is a reimplementation of the e2e build product for openshift.
|
3894c32
to
53e65f2
Compare
Since its disabled by default ; To test this, |
Should be a separate build target, and should not need sudo to build |
Yes in this case I figured as per your comment, so long as
then that satisfied the requirement of "fast builds by default".
The reason I'm asking, is that TL;DR I think we are in agreement, with one question - do we need to eliminate references to e2e from common.sh entirely? |
93197c2
to
8e7661b
Compare
pushed some more updates and rebased/cleaned. testing now. I think this might be close to consensus. |
d24af58
to
bb3629b
Compare
Okay, here are the new results. Taking into account the above suggestions regarding the Make target.
Regular build:
And for E2Es:
|
@@ -3,6 +3,7 @@ | |||
# This script provides common script functions for the hacks | |||
# Requires OS_ROOT to be set | |||
|
|||
set -o nounset |
There was a problem hiding this comment.
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.
bb3629b
to
d5c2ca4
Compare
Thanks. Ive rebased, squashed, and fixed. I think this is ready for a final look. |
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
Then, you can do |
import ( | ||
. "github.com/onsi/ginkgo" | ||
"k8s.io/kubernetes/test/e2e" | ||
"testing" |
There was a problem hiding this comment.
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
fixed the formatting for imports |
# Example: | ||
# make e2e | ||
e2e: | ||
hack/build-go.sh test/e2e/e2e.test |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
cross-ref kubernetes/kubernetes#19476 |
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. |
|
Closing, upstream alternative is pending. See the original issue for details. |
Subsumed by #7049 |
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