https://brasstacks.mozilla.com/orangefactor/ has been replaced by https://treeherder.mozilla.org/intermittent-failures.html but the OrangeFactor extension still points to brasstacks, which is due to be decommissioned. The OF extension should get its data from treeherder and provide a link to the treeherder intermittents view.
So is there a replacement API to https://brasstacks.mozilla.com/orangefactor/api/count? Also, how soon is OF to be decommissioned?
(In reply to Dylan Hardison [:dylan] (he/him) from comment #1) > Also, how soon is OF to be decommissioned? I believe no later than 2018-09-01 -- https://bugzilla.mozilla.org/show_bug.cgi?id=1367364#c1 > So is there a replacement API to > https://brasstacks.mozilla.com/orangefactor/api/count? emorley -- Can you advise, point to docs, etc?
Flags: needinfo?(gbrown) → needinfo?(emorley)
There are links to the interactive API docs in bug 1367364 comment 6, but I imagine the query that you'd need is of form: https://treeherder.mozilla.org/api/failurecount/?startday=2018-04-05&endday=2018-04-12&tree=trunk&bug=1451196
This is a P2 because we have until September, but the sooner the better I guess.
Assignee: nobody → imadueme
Priority: -- → P2
emorley: Found a difference between the two APIs - can you confirm that this is as expected? See: https://github.com/mozilla-bteam/bmo/pull/559#issuecomment-384804970
Hi! Good spot on the different counts. So I think this is happening because: * The Treeherder intermittent failures view UI uses the stats from /api/failuresbybug/ to determine the overall count in the UI * Those stats come from here: https://github.com/mozilla/treeherder/blob/6fe73c39c6c86ace5293d7e4a6cee32658a006a2/treeherder/webapp/api/intermittents_view.py#L37-L77 * Whereas the /api/failurecount/ (which is the right one to use for the graph) comes from here: https://github.com/mozilla/treeherder/blob/6fe73c39c6c86ace5293d7e4a6cee32658a006a2/treeherder/webapp/api/intermittents_view.py#L80-L125 * And the latter has an additional filter on `job__failure_classification__id=4` Having a different filter on each endpoint seems unintentional - I'll file a new bug for fixing that (that file could do with some refactoring to reduce duplication, which would help avoid differences in the future). In the meantime I'd carry on with your PR - it's not an issue with the way you're using the API :-)
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.