619508 - bugzilla search -> Orange Factor

Status: RESOLVED FIXED

(Tree Management Graveyard :: OrangeFactor, defect, P1)

Description

[Jeff Hammel]

You should be able to pass a bugzilla search to Orange Factor and
display the oranges associated with that.  Ideally going forward, a
bugzilla search result should link to and/or display a snippet of
Orange Factor for that search.

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

I see this as possibly doing a quick search (the basic bugzilla search text field, which translates to this:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=testing+orangefactor

or bzapi version:
https://api-dev.bugzilla.mozilla.org/latest/bug?quicksearch=testing+orangefactor&include_fields=id,summary

getting the json back, we can build a list of bugids and use that as our seed value.

In addition, we would need to modify our search queries to only return data about a list of bugids.  This might be possible in eslib or we can post process inside of woo_server.  I prefer not to post process too much and if it is very difficult, we can do a series of queries for each bugid and build a return object that satisfies the result value.

Can we figure out what views would benefit from this?  Maybe it is best to pick the one or two views that make the most sense to do this for.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: send a bzquery text search to generate bug list (0.5)

just a WIP.  This is hardcoded for the simulator view to show a quicksearch of browser_bug4 (this limits it to 9 instead of the 107 that match browser_).

Overall this is pretty slick.  Oddly enough my simulated orange factor was higher with this exact hardcoded query.  I need to come up with a better UI approach to this, so ideas are welcome.  Also ideas on what other views could benefit from this 'technology'.

I will clean this up over the next day or two and knock out the couple bugs related to bugzilla search.  Any feedback on this general approach is much appreciated.

Comment 4

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: support bzquery for topbugs view in orange factor (1.0)

I am not a fan of the UI, but it works and is consistent with the simulator UI.  Functionality this works as we would like it to.  

There are two other views we should consider a bzquery approach:
 - homepage Orange Factor
 - Bug Count page.

The issue with these two pages is that they are designed and make logical sense to sort by a field (platform, test type, etc...) and we would want to execute the bzquery on top of these filters instead of replace a number of bugs.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: support bzquery for orange factor view (1.0)

patch to support filtering the orangefactor based on a bzquery.  This is differrent from the topbugs and simulator because this is an additional filter to the existing filters, not a replacement.

Works great, and probably a reasonable UI although the UI could be tweaked by a UI/web designer to be cleaner and more intuitive.

Comment 6

[Mark Côté [:mcote]]

Comment on attachment 512490 [details] [diff] [review]
support bzquery for topbugs view in orange factor (1.0)

+                    $('#inputText').addClass('placeholdertext');
+                    $('#inputText').val(phText);

I actually like how you combined those into one line in other places, since I guess each call returns the element.  Might as well do that here too.

Only thing I noticed is that the value of the input box is not set if you do a quicksearch query.  If I just search for "10", then when the page reloads I see "10" in the box, but the box is empty (well, just the placeholder text) when I search for "intermittent failure".

So I think that needs to be fixed, but everything else is good.

Comment 7

[Mark Côté [:mcote]]

Oh wait, one other problem--when you change the grouping, it loses the inputText.  It should keep the same inputText.

Comment 8

[Mark Côté [:mcote]]

Comment on attachment 512506 [details] [diff] [review]
support bzquery for orange factor view (1.0)

There is a problem here.  When I search for "intermittent failures", and then after the page is loaded I try to select a test, I get this in firebug:

unterminated string literal
window.location.assign(buildUrl('Orang...01-18',endday:'2011-02-15',inputText:'

Looking at the select, I see

<select id="testruns" failure"',}));"="" intermittent="" onchange="window.location.assign(buildUrl('OrangeFactor', {plat:'All',test:this.options[this.selectedIndex].value,branch:'All',type:'All',startday:'2011-01-18',endday:'2011-02-15',inputText:'">

Something is happening when buildDropDown() is trying to insert bzquery.  Not sure exactly what's going on there, but it might be related to the problem with the other search query, where args.inputText isn't being inserted in the text-entry box if it's a string.

Comment 9

[Joel Maher ( :jmaher ) (UTC -8)]

for topbugs:
http://hg.mozilla.org/automation/orangefactor/pushloghtml?changeset=b22da066a1cd

Comment 10

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: support bzquery for orange factor view (1.1)

fixed the quoted query problem.

Comment 11

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: support bzquery for orange factor view (1.2)

ok, updated for orange factor and bugcount.  This is cleaned up a bit and once this patch is r+, we can close this bug.

Comment 12

[Mark Côté [:mcote]]

Comment on attachment 512570 [details] [diff] [review]
support bzquery for orange factor view (1.2)

Works great!  A couple code comments:

+  function buildDropDown(dataset, index, id, plat, test, branch, btype, startday, endday, args) {

Why are you passing args instead of inputText?  Seems inconsistent with the rest of the function call...

Also, the placeholder stuff should be refactored into its own function.  The same code is in 4 different places.  The actually placeholder strings differ sometimes, but the code to add and remove the text and class is the same.

Comment 13

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: support bzquery for orange factor view (1.3)

quick update on the patch I will check in with the comments addressed.

Comment 14

[Joel Maher ( :jmaher ) (UTC -8)]

http://hg.mozilla.org/automation/orangefactor/pushloghtml?changeset=876a8332658d