You won't see it unless you look quickly, but https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=f9e71f980245 has two sets of PGO builds, because I triggered a set two hours before the periodic set triggered, so I cancelled the later periodic set. Now, while my Windows ones are still running but my Linux ones are finished, we list the Linux ones as cancelled first, then finished, but we list the Windows ones as running first, then cancelled. That's confusing and silly. Because I have that kind of time, I often star the failures that b2g misrepresents as auto-RETRY, so for a particular suite there will be two retries and a success, or two retries and a failure. As I star them, they move around, so depending on the exact speed that I click on the thing to the right of a selected f10* that I just starred, there may still be another failed f10 there, or there may be an f11, because we've moved my selected job from being the first of three f10s to being the last because when it is starred it stays still, but on the next refresh from the server we shove a first-run job to the last when it is a starred first-run job. Neither "unstarred first, then starred" nor "running, then finished" is a good and useful sort, sorted by time is (particularly since it isn't going to change, and moving a particular job around within the list of that job type is a Bad Thing). If treeherder actually knows both the time scheduled and the time started, then it's a difficult call to say whether the sort should be by time scheduled or by time started, but I'm slightly more inclined to say started.
|
||
Updated•2 years ago
|
||
Description
•