Closed
Bug 1301567
Opened 9 years ago
Closed 8 years ago
Display end-to-end times of jobs in Treeherder
Categories
(Tree Management :: Treeherder, defect)
Tree Management
Treeherder
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: jgriffin, Unassigned)
References
(Blocks 1 open bug)
Details
During a debugging UX meeting today, we decided it would be nice if Treeherder would display the end-to-end time for all the jobs of a push; it would be a single number representing the time between initial job scheduled and last job completed (or the present, if there are pending/running jobs).
This would help developers understand the E2E time, and hopefully demonstrate incremental improvements as we make them.
Comment 1•9 years ago
|
||
Hahaha, you said "simple."
If you are talking about Try-only, it's conceptually fairly simple: you see a push, with zero or one job, and avoid saying it has an E2E time of 0s if you see zero jobs, and then maybe have a risky time when the decision task might be finished before you see tasks it triggers or see buildbot jobs, and from then on you're probably fine, unless taskcluster builds finish at the same time they trigger tests, but mostly it's straightforward. -ish, since there exist jobs that never finish and you'll be telling people that their push has been running for two weeks, but in a way it has. And if they retrigger on it four days later, whether you stick with the original 4 hours or say the E2E is now 4 days, eh, they did it to themselves.
If you are also talking about non-Try, good luck. It should be every bit as accurate as the "percent complete" which I've thought multiple times about filing against to say it should be removed, because it's such a lie. With coalescing, and SETA scheduling, a push can go from showing zero pending/running jobs to showing hundreds to showing ten forever, all without actually running another job directly on the push, and when a push is finished is pretty much undefined. Coalescing happens based on the time a job was requested, so with pushes A B C D, if C does a fast build, schedules a test but there's no free slave to pick it up, then A finishes a slow clobbered build and schedules the same test, the test for C will be coalesced back onto A, and C is "done" when that test runs on D, despite there being no tie between the two other than a human saying "nope, not done yet, there's no Win7 opt xpcshell on that push and no finished one above it, okay now it's done because of that finished one up there."
And then a couple hours later, we schedule PGO on it.
Comment 2•8 years ago
|
||
For similar reasons to bug 1052397.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•