Closed
Bug 1048043
Opened 10 years ago
Closed 9 years ago
Add a message if the specified revision does not exist (or has not been ingested yet)
Categories
(Tree Management :: Treeherder, defect, P2)
Tree Management
Treeherder
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: emorley, Assigned: KWierso)
References
Details
Attachments
(2 files)
After pushing to try, within 10-20 seconds, the new push is visible on hgweb pushlog and thus TBPL. However it took 5-6 mins for it to appear on https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=349e5eb93687
![]() |
||
Comment 1•9 years ago
|
||
This may seem trivial, but when you're pushing to try and you need to post a link to a bug, this can be a real pita.
Comment 2•9 years ago
|
||
There's a combination of issues here: - treeherder doesn't display new result set unless there is at least a new job attached to it. - treeherder sometimes takes a couple of minutes to be aware of new result sets. Given that new jobs are fetched from buildapi once a minute and are discarded if the result set they belong to hasn't been loaded yet we could have a situation where the time to display a new resultset could take a few minutes as reported by :edmorley I think the best way to mitigate this issue is to 1) Show empty result sets in the ui as soon as they are available. This can be done broadcasting a socket.io event very much like we do for new jobs 2)change the way treeherder ingests new result sets. At the moment this is done polling hg.m.o every minute for changes. We could use a pulse consumer to get the updates and eventually fetch the push details with a quick request to https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?full=1&rev=e8425ac082d7. AFAIK 2) depends on Bug 1022701, but we can start implementing 1) separately.
Depends on: 1022701
Reporter | ||
Comment 3•9 years ago
|
||
Thank you for looking at this :-) I think there's also: 3) Make sure that if someone clicks a try link (eg the one output from the hg.mozilla.org response after pushing to try), the resultant page: a) Displays a useful message "Unknown push" b) Refreshes automatically when the backend ingests that push, so the user doesn't have to refresh the page.
Reporter | ||
Comment 4•9 years ago
|
||
(In reply to Ed Morley [:edmorley] from comment #3) > a) Displays a useful message "Unknown push" To be clearer: a) Displays a useful message (eg "Unknown push") if the backend hasn't yet ingested it (ie in the 60s between polls, or if the hg pushlog is erroring out temporarily a la bug 1040308).
Comment 5•9 years ago
|
||
Yeah, we could start with a). b) would come for free if we implement point number 1 described in comment 2
Assignee | ||
Comment 6•9 years ago
|
||
This adds a brief message informing the user that Treeherder currently doesn't know about the specified revision, whether that's because the revision doesn't actually exist or because that push just hasn't been processed yet. I've tested it locally with a try push, and the message will appear for a minute or so before eventually being replaced with the actual push information once Treeherder processed the push.
Attachment #8486094 -
Flags: review?(cdawson)
Attachment #8486094 -
Flags: feedback?(emorley)
Assignee | ||
Comment 7•9 years ago
|
||
Attachment #8486104 -
Flags: feedback?(emorley)
Assignee | ||
Updated•9 years ago
|
Attachment #8486094 -
Flags: feedback?(emorley)
Updated•9 years ago
|
Attachment #8486094 -
Flags: review?(cdawson) → review+
Assignee | ||
Comment 8•9 years ago
|
||
https://github.com/mozilla/treeherder-ui/commit/93cff5b002dc7bca43e591b371859184aa2d7e1e
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•9 years ago
|
||
(In reply to Ed Morley (At work week 6th-13th Sept) [:edmorley] from comment #3) > Thank you for looking at this :-) > > I think there's also: > > 3) Make sure that if someone clicks a try link (eg the one output from the > hg.mozilla.org response after pushing to try), the resultant page: > a) Displays a useful message "Unknown push" > b) Refreshes automatically when the backend ingests that push, so the user > doesn't have to refresh the page. Well, part A is done, and from my testing, part B already happens. Reopening so that we can reduce the amount of time it takes for Treeherder to process incoming pushes by either polling for changes more frequently or having a push hook that manually signals Treeherder to process a new push.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•9 years ago
|
Summary: New try pushes take a long time to appear on treeherder → Reduce the amount of time it takes for new pushes to appear in Treeherder.
Reporter | ||
Updated•9 years ago
|
Attachment #8486104 -
Flags: feedback?(emorley) → feedback+
Reporter | ||
Comment 10•9 years ago
|
||
To keep things easier to track, I've broken the remaining issues out of this bug: * Bug 1065568 - Make the pushlog ingestion cron more frequent * Bug 1065576 - Result sets containing no jobs only appear in the UI after a page reload * Bug 1065567 - Use pulse for quicker pushlog ingestion rather than polling json-pushes Tweaking summary for this bug to reflect the part that was done here - bug 1065541 tracks the further tweaks needed to the patch.
Assignee: nobody → kwierso
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
No longer depends on: 1022701
Resolution: --- → FIXED
Summary: Reduce the amount of time it takes for new pushes to appear in Treeherder. → Add a message if the specified revision does not exist (or has not been ingested yet)
Comment 11•9 years ago
|
||
Commits pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/d6228d3f966c4e239205fe9c3fd5066f57b92440 Bug 1048043 - Add a message for when a revision ID cannot be found. https://github.com/mozilla/treeherder/commit/c652d5603100b78369186ad64a7686d05be633b7 Merge pull request #155 from KWierso/1048043 Bug 1048043 - Add message for when revision not found.
You need to log in
before you can comment on or make changes to this bug.
Description
•