add completion time field to builds

[bparees]

No description provided.

[bparees]

fixes #332

@jwforres @smarterclayton ptal. I took an executive action and took pod completion time (actually the time at which the build controller notices the pod is complete) as the build completion timestamp.

[bparees]

[test]

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1357/)

[jwforres]

so we know the build object's creationTimestamp and completionTimestamp, but we don't know the creationTimestamp of the pod that was actually running the build, so we don't know the difference between when we asked for the build and when the build actually started running? how big do we expect that diff to be? Just thinking with Jenkins / Travis that builds aren't considered started until they are actually running.

[jwforres]

You should add this to the Browse -> Builds page while you are at it? Ideally as a diff between creationTimestamp and completionTimestamp, i.e. "Build completed in 5 minutes" or something like that.

[bparees]

if @smarterclayton is ok w/ the change, yeah i can add that to the PR.

as for the question of when it started... there shouldn't be a huge difference...the biggest factor is liable to be pulling the builder image, if that is needed, or the pod not getting scheduled at all due to resource constraints.

I could add another field that we set when the pod enters the "running" state, but that leaves us with the possibility of having builds that get a completion timestamp (when they are canceled) and no start timestamp (because when did it "start")? i'm inclined to say this is "good enough" since technically it is tracking when the build object was created.

[bparees]

discussed w/ @jwforres and leaning towards adding a "buildStartTime" field that gets set when the pod enters running state, and using the existing creationTimestamp as a "build requested at" value.

[bparees]

@jwforres ptal. here's what describe outputs now... I went w/ belt+suspenders in outputting start/finish/duration if both start+finish are available:

Name: ruby-sample-build-31e1e8c5-ccec-11e4-bccb-3c970e3bf0b7
Created: 2015-03-17 17:25:54 -0400 EDT
Labels: buildconfig=ruby-sample-build,name=ruby-sample-build,template=application-template-stibuild
Status: Complete
Started: 2015-03-17 17:26:19 -0400 EDT
Finished: 2015-03-17 17:29:09 -0400 EDT
Duration: 2m50s
Build Pod: build-ruby-sample-build-31e1e8c5-ccec-11e4-bccb-3c970e3bf0b7
Strategy: STI
Image: openshift/ruby-20-centos7
Incremental Build: yes
Source Type: Git
URL: git://github.com/openshift/ruby-hello-world.git
Output to: origin-ruby-sample
Output Spec: 172.30.17.158:5000/test/origin-ruby-sample

[jwforres]

@smarterclayton have you considered doing relative timestamps in calls to describe? like we do in the web console. Something like... 5 minutes ago (2015-03-17 17:26:19 -0400 EDT)

[smarterclayton]

Yes, it's done for pods already so it'd be natural to extend

On Mar 18, 2015, at 9:17 AM, Jessica Forrester notifications@github.com wrote:

@smarterclayton have you considered doing relative timestamps in calls to describe? like we do in the web console. Something like... 5 minutes ago (2015-03-17 17:26:19 -0400 EDT)

—
Reply to this email directly or view it on GitHub.

[jwforres]

@bparees discussed with @smarterclayton can you make the timestamps relative, just 5 minutes ago no timestamp

[jwforres]

Thought about this some more.. make Created relative. For started/finish timestamps if you really want to show them, they probably should just be timestamps since saying started 5 days ago and finished 5 days ago isn't very useful. But all we really need to display is created and duration. It would be nice if Duration was something like...

When waiting to start... (thinking if my build has been stuck in pending for 5 hours i probably care about that and will want to know to bug someone that the build queue is stuck)
Duration: waiting for 5 minutes

When running... (just seeing a started timestamp doesn't immediately tell me anything, seeing how long its been running for immediately tells me if my build is stuck, if say i know it normally runs much faster)
Duration: running for 5 minutes

When completed...
Duration: ran for 5 minutes or maybe just Duration: 5 minutes

[bparees]

Pending builds:
Name: ruby-sample-build-829bb313-cd97-11e4-94c6-3c970e3bf0b7
Created: 2015-03-18 13:52:14 -0400 EDT
Status: Pending
Duration: waiting for 7s

Running builds:
Name: ruby-sample-build-829bb313-cd97-11e4-94c6-3c970e3bf0b7
Created: 2015-03-18 13:52:14 -0400 EDT
Status: Running
Started: 2015-03-18 13:52:42 -0400 EDT
Duration: running for 39s

Completed builds:
Name: ruby-sample-build-4ad9a989-cd96-11e4-94c6-3c970e3bf0b7
Created: 2015-03-18 13:43:31 -0400 EDT
Status: Failed
Started: 2015-03-18 13:44:02 -0400 EDT
Finished: 2015-03-18 13:45:22 -0400 EDT
Duration: 1m20s

acceptable, at least for now?

[jwforres]

Acceptable for now, should look into using something like https://github.com/dustin/go-humanize#times in the future

[bparees]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1220/) (Image: devenv-fedora_1077)

[bparees]

[merge]

[openshift-bot]

Evaluated for origin up to 066cb50