Skip to content
This repository has been archived by the owner on Sep 5, 2019. It is now read-only.

Update build execution time #335

Merged
merged 16 commits into from
Sep 11, 2018

Conversation

shashwathi
Copy link
Contributor

@shashwathi shashwathi commented Sep 5, 2018

Proposed Changes

  • Update build execution time to be (build finish time - pod start time)
  • Add integration test to check build status

@shashwathi shashwathi changed the title [WIP] Update build execution time Update build execution time Sep 7, 2018
@shashwathi
Copy link
Contributor Author

/assign @imjasonh
/assign @pivotal-nader-ziada

}
}

func TestBuildWithHighTimeout(t *testing.T) {
Copy link
Member

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

Copy link
Member

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

Copy link
Contributor Author

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
t.Fatalf("watchBuild did not return expected BuildTimeout error")
}

// verify reason for build failure is timeout
Copy link
Member

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.

Copy link
Contributor Author

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)?

Copy link
Member

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.

Copy link
Contributor Author

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.


b, err := clients.buildClient.watchBuild(buildName)
if err == nil {
t.Fatalf("watchBuild did not return expected BuildTimeout error")
Copy link
Member

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.

}
}

func TestBuildWithHighTimeout(t *testing.T) {
Copy link
Member

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

Shash Reddy added 4 commits September 7, 2018 14:23
- 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.
@shashwathi
Copy link
Contributor Author

@imjasonh @pivotal-nader-ziada : Addressed all comments and fixed e2e tests. Please take a look at this and provide feedback

@nader-ziada
Copy link
Member

/lgtm

@@ -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
Copy link
Member

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",
Copy link
Member

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?

Copy link
Contributor Author

@shashwathi shashwathi Sep 10, 2018

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.

@shashwathi
Copy link
Contributor Author

shashwathi commented Sep 10, 2018

If timeout is not specified then it will be equal to 0 and thats valid input. so I will update the logic to below

if timeout < 0 {
  // bad
} else if timeout > maxTimeout {
  // bad
}
// good

WDYT? @imjasonh

@shashwathi
Copy link
Contributor Author

shashwathi commented Sep 10, 2018

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

@nader-ziada
Copy link
Member

I would prefer as a user to enter the build timeout in seconds, not nanoseconds.

@shashwathi
Copy link
Contributor Author

/test pull-knative-build-integration-tests

@shashwathi
Copy link
Contributor Author

/test pull-knative-build-integration-tests

@imjasonh
Copy link
Member

I would prefer as a user to enter the build timeout in seconds, not nanoseconds.

Agreed. I would have thought Go would be smart enough to accept the string form of a time.Duration while JSON-unmarshalling, but apparently it's not, and that's just gross.

Sorry for the back-and-forth, but if Go's not going to let us say timeout: 3m18s and instead will make me do math (ugh), then I think we should have the field be a string and to the duration parsing ourselves. 😞

@shashwathi
Copy link
Contributor Author

I will update the PR with build duration as string. 👍

@knative-metrics-robot
Copy link

The following is the coverage report on pkg/.
Say /test pull-knative-build-go-coverage to run the coverage report again

File Old Coverage New Coverage Delta
pkg/controller/build/controller.go 50.0% 50.4% 0.4

@shashwathi
Copy link
Contributor Author

@imjasonh : Addressed all comments. Let me know if you have any comments on this PR.

Copy link
Member

@imjasonh imjasonh left a 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"
Copy link
Member

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.

Copy link
Contributor Author

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"
Copy link
Member

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
Copy link
Member

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.

@knative-prow-robot
Copy link

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tcnghia
Copy link

tcnghia commented Sep 17, 2018

@shashwathi @imjasonh can we use https://github.com/kubernetes/apimachinery/blob/master/pkg/apis/meta/v1/duration.go instead of strings here?

@shashwathi
Copy link
Contributor Author

Thats a great idea. We rejected the idea of using time.Duration because native Golang time Duration does not support strings unmarshal. I can follow up with a PR to use k8s duration type. Thanks for finding that @tcnghia

@shashwathi shashwathi deleted the update-execution-time branch September 18, 2018 13:40
vdemeester pushed a commit to vdemeester/knative-build that referenced this pull request Apr 3, 2019
* 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
vdemeester pushed a commit to vdemeester/knative-build that referenced this pull request Apr 3, 2019
* 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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants