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

extended tests for jenkins openshift V3 plugin #6329

Merged
merged 1 commit into from Jan 9, 2016

Conversation

gabemontero
Copy link
Contributor

return data
}

var _ = g.Describe("jenkins: plugin: run job leverging openshift pipeline plugin", func() {
Copy link
Contributor

Choose a reason for hiding this comment

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

leveraging

@gabemontero
Copy link
Contributor Author

@bparees updates based on 1st set of comments

@@ -189,22 +189,22 @@ var CheckImageStreamTagNotFoundFn = func(i *imageapi.ImageStream) bool {
func WaitForADeployment(client kclient.ReplicationControllerInterface,
Copy link
Contributor

Choose a reason for hiding this comment

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

I think i would have done this differently.... either:

  1. just check the start time and calculate and end time, and then if the end time has passed at the top of the outer loop
  2. get rid of the the Watch entirely and just wrap the list() in a wait.Poll check (which is basically what WaitForABuild does).

with the existing logic it's pretty hard to follow how long it's really going to end up waiting, based on expiration of watches. also 3 minutes between polls seems like a lot.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

went with option 1) ... will push in a sec

//NewApp performs an oc new-app invocation from the supplied json file
func NewApp(jsonFilePath string, oc *CLI) error {
err := oc.Run("new-app").Args(jsonFilePath).Execute()
return err
Copy link
Member

Choose a reason for hiding this comment

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

just return the oc.Run here :-)

Copy link
Member

Choose a reason for hiding this comment

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

is this worth to have special function? I think reading the code will tell you what this does.... having NewApp() makes you go find the definition if something explode :)

@gabemontero
Copy link
Contributor Author

hack/install-assets.sh failed ... never got to the extended tests in the extended test run

@@ -189,7 +189,9 @@ var CheckImageStreamTagNotFoundFn = func(i *imageapi.ImageStream) bool {
func WaitForADeployment(client kclient.ReplicationControllerInterface,
name string,
isOK, isFailed func(*kapi.ReplicationController) bool) error {
for {
startTime := time.Now()
endTime := startTime.Add(3 * time.Minute)
Copy link
Contributor

Choose a reason for hiding this comment

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

bump this up to something like 15 or 20 minutes. we don't want to introduce flakes if we have existing extended tests that take a long time waiting for a deployment for some reason.

i'm also surprised 3 minutes is long enough for you test, given that it basically has to get through the entire imagebuild+deploy step in 3 minutes to pass.

(3 minutes or the watch timeout, whichever is longer.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do - it worked for me locally but i did not measure how long it
typically took

On Wednesday, December 16, 2015, Ben Parees notifications@github.com
wrote:

In test/extended/util/framework.go
#6329 (comment):

@@ -189,7 +189,9 @@ var CheckImageStreamTagNotFoundFn = func(i _imageapi.ImageStream) bool {
func WaitForADeployment(client kclient.ReplicationControllerInterface,
name string,
isOK, isFailed func(_kapi.ReplicationController) bool) error {

  • for {
  • startTime := time.Now()
  • endTime := startTime.Add(3 * time.Minute)

bump this up to something like 15 or 20 minutes. we don't want to
introduce flakes if we have existing extended tests that take a long time
waiting for a deployment for some reason.

i'm also surprised 3 minutes is long enough for you test, given that it
basically has to get through the entire imagebuild+deploy step in 3 minutes
to pass.

(3 minutes or the watch timeout, whichever is longer.)


Reply to this email directly or view it on GitHub
https://github.com/openshift/origin/pull/6329/files#r47846861.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm guessing the watch doesn't get closed because there's not much etcd
change log activity, so you don't come back to the top of the loop, so the
3 minute limit doesn't come into play in your particular scenario.

Ben Parees | OpenShift
On Dec 16, 2015 10:20 PM, "Gabe Montero" notifications@github.com wrote:

In test/extended/util/framework.go
#6329 (comment):

@@ -189,7 +189,9 @@ var CheckImageStreamTagNotFoundFn = func(i _imageapi.ImageStream) bool {
func WaitForADeployment(client kclient.ReplicationControllerInterface,
name string,
isOK, isFailed func(_kapi.ReplicationController) bool) error {

  • for {
  • startTime := time.Now()
  • endTime := startTime.Add(3 * time.Minute)

Will do - it worked for me locally but i did not measure how long it
typically took
… <#151adf41a51c75cf_>
On Wednesday, December 16, 2015, Ben Parees notifications@github.com
wrote: In test/extended/util/framework.go <#6329 (comment)
https://github.com/openshift/origin/pull/6329#discussion_r47846861>: >
@@ -189,7 +189,9 @@ var CheckImageStreamTagNotFoundFn = func(i
_imageapi.ImageStream) bool { > func WaitForADeployment(client
kclient.ReplicationControllerInterface, > name string, > isOK, isFailed
func(_kapi.ReplicationController) bool) error { > - for { > + startTime :=
time.Now() > + endTime := startTime.Add(3 * time.Minute) bump this up to
something like 15 or 20 minutes. we don't want to introduce flakes if we
have existing extended tests that take a long time waiting for a deployment
for some reason. i'm also surprised 3 minutes is long enough for you test,
given that it basically has to get through the entire imagebuild+deploy
step in 3 minutes to pass. (3 minutes or the watch timeout, whichever is
longer.) — Reply to this email directly or view it on GitHub <
https://github.com/openshift/origin/pull/6329/files#r47846861>.


Reply to this email directly or view it on GitHub
https://github.com/openshift/origin/pull/6329/files#r47865373.

@gabemontero gabemontero force-pushed the jenkinsExtendedTests branch 2 times, most recently from 2b5af4b to 870339a Compare December 17, 2015 13:30
@gabemontero
Copy link
Contributor Author

the test only extended keep failing in a early, just after build-go.sh completes successfully, in a weird way, way before it gets to the extended test.

tried refreshing the branch; if still fails, going to remove the existing test flags and just try a generic test job.

@gabemontero
Copy link
Contributor Author

ok ... it looks like it got to try and run the extended test, but it seems to fail immediately with an error that is not obvious to me at first blush:

Running TEST_REPORT_DIR=/tmp/openshift-extended-tests/junit/extended test/extended/core.sh --ginkgo.focus="jenkins"...
package k8s.io/kubernetes/pkg/util
imports github.com/davecgh/go-spew/spew
imports github.com/docker/libcontainer/cgroups/fs
imports github.com/docker/docker/pkg/mount
imports github.com/docker/docker/pkg/units
imports github.com/docker/docker/pkg/units
imports github.com/docker/docker/pkg/units: cannot find package "github.com/docker/docker/pkg/units" in any of:
/usr/lib/golang/src/github.com/docker/docker/pkg/units (from $GOROOT)
/data/src/github.com/docker/docker/pkg/units (from $GOPATH)

I'm going to see about clearing all the prior test flags, see if I can get full fledged test going.

@mfojtik
Copy link
Member

mfojtik commented Dec 17, 2015

@gabemontero why do you import "github.com/docker/docker/pkg/units" ?

@mfojtik
Copy link
Member

mfojtik commented Dec 17, 2015

OK this seems like kubernetes imports that package... that is weird, do you have godeps setup properly?

@gabemontero
Copy link
Contributor Author

@mfojtik I don't import "github.com/docker/docker/pkg/units" .... as far as i know i do, I did not make any godeps changes as part of this PR ... in any event, wouldn't the test job on jenkins be the one that pulls the various godeps?

@mfojtik
Copy link
Member

mfojtik commented Dec 17, 2015

@gabemontero I just ran that command and it worked for me, that means that you might have something wrong with your environment... can you check the value of GOPATH?

@bparees
Copy link
Contributor

bparees commented Dec 17, 2015

lgtm, waiting for extended test framework to be fixed up.

@gabemontero
Copy link
Contributor Author

[testonlyextended][extended:core(jenkins)]

@gabemontero
Copy link
Contributor Author

back to testing, having pulled in pr #6558 while it is waiting to merge, and uncovered a timing issue panic in the wait for jenkins to come up logic ... pushing an update for retest shortly.

@gabemontero
Copy link
Contributor Author

ok ... the new extended test just passed !! ... Going to push the back out of the 6558 fix, confirm things are still good

@gabemontero
Copy link
Contributor Author

OK that's two straight successful extended test runs. And the travis hiccup appears to be some sort of go 1.4 flake (it works in 1.5).

@bparees IMO - this is ready to hit the merge button on - PTAL at your convenience / discretion

}
}

// as g.It's are added conceivably will be with new jenkins job def's
Copy link
Contributor

Choose a reason for hiding this comment

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

scrambled godoc

Copy link
Contributor

Choose a reason for hiding this comment

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

or scrambled comment. not sure what it was intended to be.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

just deleted - no longer pertinent as I recall

@bparees
Copy link
Contributor

bparees commented Jan 7, 2016

one nit and a question about the deployment that's being verified. otherwise lgtm.

@gabemontero
Copy link
Contributor Author

ok ... i've pushed the updates in response to the one nit and question

@bparees
Copy link
Contributor

bparees commented Jan 8, 2016

lgtm [merge]

@openshift-bot
Copy link
Contributor

[Test]ing while waiting on the merge queue

@gabemontero
Copy link
Contributor Author

the https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/8311/ failure came from hack/../test/cmd/volumes.sh, prior to the launching of the extended tests

the https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/4555/ failure came from hack/../test/cmd/images.sh

can we re-hit the merge button or force the merge of this new extended test (which passed here: https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/8309/) ?

@bparees
Copy link
Contributor

bparees commented Jan 8, 2016

i can keep hitting it, but until we sort out the underlying etcd flake issue, don't hold your breath
[merge]

(I don't want to force merge even though this would be low risk, it's just a bad pattern to get into. we need to fix the merge queue)

@gabemontero
Copy link
Contributor Author

@bparees roger that

@bparees
Copy link
Contributor

bparees commented Jan 8, 2016

[merge]

@deads2k
Copy link
Contributor

deads2k commented Jan 9, 2016

[test]

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/4584/) (Image: devenv-rhel7_3110)

@deads2k
Copy link
Contributor

deads2k commented Jan 9, 2016

Gofmt, not a flake

@openshift-bot
Copy link
Contributor

Evaluated for origin testonlyextended up to 2b35c51

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 2b35c51

@gabemontero
Copy link
Contributor Author

yep, found 1 more thing to fix last night, failed to gofmt ... just pushed

if needed somebody please hit merge button when get the chance - thx

@bparees
Copy link
Contributor

bparees commented Jan 9, 2016

[merge]

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 2b35c51

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/testonlyextended SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/8413/) (Extended Tests: core(jenkins))

openshift-bot pushed a commit that referenced this pull request Jan 9, 2016
@openshift-bot openshift-bot merged commit ad80e1f into openshift:master Jan 9, 2016
@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/8414/) (Extended Tests: core(jenkins))

@gabemontero gabemontero deleted the jenkinsExtendedTests branch January 10, 2016 22:41
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.

None yet

6 participants