-
Notifications
You must be signed in to change notification settings - Fork 157
Update build execution time #335
Update build execution time #335
Conversation
/assign @imjasonh |
test/e2e/simple_test.go
Outdated
} | ||
} | ||
|
||
func TestBuildWithHighTimeout(t *testing.T) { |
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.
Not sure you need this test here, since the build is actually successful
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.
+1, our test that a build under the timeout passes is TestSimpleBuild
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 agree. I wanted to test a build with higher timeout set. As an alternate idea I could alter the SimpleBuild
test to have a timeout as well.
- Add comments
test/e2e/simple_test.go
Outdated
t.Fatalf("watchBuild did not return expected BuildTimeout error") | ||
} | ||
|
||
// verify reason for build failure is timeout |
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.
Can we add a check that the build executed for 20s, +/- some wiggle room? That wiggle room will be pretty high today, since we only poll every 30s.
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.
Okay how about we check if build duration is between buildTimeout and buildTimeout + 40s(30s poll + 10s tolerance)?
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.
Yeah that sounds good. Add a TODO to reduce the wiggle room once we're more strict, and maybe run the test a few times to make sure it's not flaky.
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 ran into couple of edge cases while re-running the test. So I fixed couple of bugs in this PR.
test/e2e/simple_test.go
Outdated
|
||
b, err := clients.buildClient.watchBuild(buildName) | ||
if err == nil { | ||
t.Fatalf("watchBuild did not return expected BuildTimeout error") |
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.
This could probably be t.Error
, and we can keep checking other things about the returned build.
test/e2e/simple_test.go
Outdated
} | ||
} | ||
|
||
func TestBuildWithHighTimeout(t *testing.T) { |
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.
+1, our test that a build under the timeout passes is TestSimpleBuild
- Fix build completed time bug for cancelle builds
- If build node selector is not present build never timesout, then e2e never fail/succeed. - Moved bad node selector test into e2e so its easier to test that build is in pending state until build watch exits.
@imjasonh @pivotal-nader-ziada : Addressed all comments and fixed e2e tests. Please take a look at this and provide feedback |
/lgtm |
pkg/builder/interface.go
Outdated
@@ -75,7 +75,8 @@ func IsDone(status *v1alpha1.BuildStatus) bool { | |||
return false | |||
} | |||
|
|||
// IsTimedOut returns true if the build's status indicates that build is timedout. | |||
// IsTimeOut returns true if the build's execution time is greater than |
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: IsTimeout
(lowercase o
)
@@ -82,6 +83,7 @@ func TestSimpleBuild(t *testing.T) { | |||
Name: buildName, | |||
}, | |||
Spec: v1alpha1.BuildSpec{ | |||
Timeout: "40s", |
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.
Can we use an actual time.Duration
for this field?
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.
Thats a great idea. I have updated the PR with this change.
If timeout is not specified then it will be equal to 0 and thats valid input. so I will update the logic to below
WDYT? @imjasonh |
Go serializes Duration in nanoseconds. User needs to be aware of this conversion. I have added more comments in spec and test as well. I will update the docs after this PR is merged. I am not sure of this change anymore. Strings made it simple and readable format for developer. Thoughts @imjasonh @pivotal-nader-ziada @mattmoor |
I would prefer as a user to enter the build timeout in seconds, not nanoseconds. |
/test pull-knative-build-integration-tests |
/test pull-knative-build-integration-tests |
Agreed. I would have thought Go would be smart enough to accept the string form of a Sorry for the back-and-forth, but if Go's not going to let us say |
I will update the PR with build duration as string. 👍 |
The following is the coverage report on pkg/.
|
@imjasonh : Addressed all comments. Let me know if you have any comments on this PR. |
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.
/lgtm
/approve
@@ -18,7 +18,7 @@ metadata: | |||
labels: | |||
expect: failed | |||
spec: | |||
timeout: 50s | |||
timeout: "50s" |
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.
These quotes aren't necessary right? I don't feel strongly about removing them, I just want to make sure this all works if a user doesn't explicitly quote the string.
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.
Quotes are not necessary. When I changed the type into string I might have gone on a spree to add quotes everywhere :D I will follow up with a PR to address all your comments.
clients := setup(t) | ||
|
||
buildName := "build-low-timeout" | ||
buildTimeout := "50s" |
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.
Optional: buildTimeout = 50*time.Second
then Timeout: buildTimeout.String()
means you don't have to parse and handle the error down on line 169. Up to you, it's also fine like this.
if err != nil { | ||
t.Errorf("Error parsing build duration: %v", err) | ||
} | ||
higherEnd := 90 * time.Second // build timeout + 30 sec poll time + 10 sec |
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 this value is intended to be based on buildTimeout
, maybe it should explicitly be based on it?
higherEnd := buildTimeout + 30*time.Second + 10*time.Second
That way if we change buildTimeout
above we won't also have to remember to update this value.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ImJasonH, shashwathi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@shashwathi @imjasonh can we use https://github.com/kubernetes/apimachinery/blob/master/pkg/apis/meta/v1/duration.go instead of strings here? |
Thats a great idea. We rejected the idea of using |
* build execution time=(build finish time - pod start time) * Add e2e tests for build with low and high timeout * Remove redundant test - Add comments * Add assertion for build duration - Fix build completed time bug for cancelle builds * Reduce timeout for faster feedback * Fix unit test * Move bad node selector into e2e from YAML test - If build node selector is not present build never timesout, then e2e never fail/succeed. - Moved bad node selector test into e2e so its easier to test that build is in pending state until build watch exits. * Update timeout from string to duration * update build duration for timeout * Address comments * Fix timeout logic * Refactor and address comments * Update timeout in test * Revert to using build duration as string instead of Duration * go fmt update * Update test build with string timeout
* build execution time=(build finish time - pod start time) * Add e2e tests for build with low and high timeout * Remove redundant test - Add comments * Add assertion for build duration - Fix build completed time bug for cancelle builds * Reduce timeout for faster feedback * Fix unit test * Move bad node selector into e2e from YAML test - If build node selector is not present build never timesout, then e2e never fail/succeed. - Moved bad node selector test into e2e so its easier to test that build is in pending state until build watch exits. * Update timeout from string to duration * update build duration for timeout * Address comments * Fix timeout logic * Refactor and address comments * Update timeout in test * Revert to using build duration as string instead of Duration * go fmt update * Update test build with string timeout
Proposed Changes