1327596 - Mozregression can't bisect some bugs, because builds are stored on the server in a wrong way

Status: NEW

(Testing :: General, defect, P3)

Description

[arni2033]

>>>   My Info:   Win7_64,   GUI Version 0.9.4   Using mozregression version 2.3.8
STR_1:
1. Open mozregression, start bisection (Firefox 32 bit, between 2016-06-30 and 2016-07-03)
2. Perform bisection using these steps:
  2.1. Open url [1] in a new tab
  2.2. Open web console
  (mark builds as "bad" if source location takes 40% of console and "good" if location is short)

> [1] data:text/html,<title>Ready</title><script>function Busy(){document.title=Date.now()+" "+"Busy";setTimeout(function(){var D=Date.now()+(+I.value);while(Date.now()<D){}document.title=Date.now()+" "+"Ready";},0)}</script><button id="B" onclick="/*Busy()*/">Busy</button><br>Timeout: <input id="I" value="10000"> milliseconds


AR:  Mozregression searches builds in wrong branch (See Note). As a result I get this pushlog
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fcec96be60dbdc28870c8bbb92af7fc0b1d7709a&tochange=b8d9d1486f5bf55ce10d082e19f511498165c2d9

ER:  Mozregression should search builds in correct branch. The following pushlog is expected:
> https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=c6ce12a74300f69b8a8aabc2677aa4710809194a&tochange=975d97ff77ae82b113b66d2a46dc30fc654f411a


Note:
Look at this pushlog (between 2016-07-01 and 2016-07-02).
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fdcee57b4e4f66a82831ab01e61500da98a858e8&tochange=39dffbba764210b25bfc1e749b4f16db77fa0d46
The builds placed at the bottom are supposed to be older then builds placed at the top.
However, builds placed at the top are older than builds at the bottom - look at build ID:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7c72118d085a - Build ID is 20160630232622
https://hg.mozilla.org/integration/fx-team/rev/49a1d28776b4 - Build ID is 20160701182722
So I think there's nothing wrong with mozregression. Either way developers may want
to implement some protection from such cases into mozregression.