Closed Bug 1043320 Opened 10 years ago Closed 10 years ago

Job details: Job start time is missing from running/pending jobs

Categories

(Tree Management :: Treeherder, defect, P1)

Product:
Tree Management
Component:
Treeherder
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: emorley, Assigned: camd)

References

Details

Migrated from: https://github.com/mozilla/treeherder-ui/issues/79 Original summary: Start time should not be displayed as the birth of the timestamp if not set #79 lightsofapollo commented on 26 May: > Showing: 12/31/69 4:00 PM is somewhat disturbing... I imagine the rea > problem is the start time is not sent by buildbot pulse messages or is > and not ingested (we are fixing same problem on TC end)
Summary: treeherder-ui should not display a start time of "12/31/69 4:00 PM" if the timestamp was not set → treeherder-ui: don't display a start time of "12/31/69 4:00 PM" if the timestamp was not set
So tbpl displayed the correct timestamp, but tree herder does not until the job completes (in my experience)
I noticed this today, and I'm wondering if it's also responsible for the bogus completion statistics one sees when hovering over a build, e.g. "running, 14 minutes overdue, typically takes 30 minutes" (been running for about five minutes tops).
Priority: P3 → P2
Summary: treeherder-ui: don't display a start time of "12/31/69 4:00 PM" if the timestamp was not set → Job start time is not set until the job completes
iirc we talked about having the ability to distinguish between "job request time" and "job started time" (TBPL just uses the former), I can't remember whether that's something we included in the data model.
Summary: Job start time is not set until the job completes → Job start time is missing from running/pending jobs
Summary: Job start time is missing from running/pending jobs → Job details: Job start time is missing from running/pending jobs
Telling when a job started, even if it is still running/pending is pretty important for diagnosing issues when sheriffing (as well as trying to predict when a retrigger will complete, in order to tell how long before a repo can be reopened), so making this a P1.
Priority: P2 → P1
Assignee: nobody → cdawson
Status: NEW → ASSIGNED
The UI portion of this is fixed in: https://github.com/mozilla/treeherder-ui/commit/1870f37449fb0c48d7a94f39056eec1819658c8a This cleans up the display of times in general as well. If we don't have an end time, then we base duration off of ``now``. If we don't have a start time, then we base the beginning of the duration off of the request time. I also grouped all the times/duration together to make it more logically read-able. However, there is a service portion as well. Ends up we weren't persisting the start_timestamp value for running jobs at all! Only for completed jobs. That'll come in another commit.
https://github.com/mozilla/treeherder-service/commit/b05c507b46c9965f8a953d67e7d82a7d0d2f036e This commit fixes the service part, which ensures that we ingest the start_timestamp on running jobs.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Blocks: 1060761
You need to log in before you can comment on or make changes to this bug.