1084962 - mozregression stopped when there were still inbound builds

Status: RESOLVED WORKSFORME

(Testing :: mozregression, defect)

Description

[Mike Hommey [:glandium]]

I was bisecting with this:
   mozregression --bad=2014-10-17 --good=2014-08-30

And got down to:
  No more inbounds to bisect
  Last good revision: 78a4540b0a9c
  First bad revision: d5c1c2837d53
  Pushlog:
  https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=78a4540b0a9c&tochange=d5c1c2837d53

As the pushlog shows, there are more to bisect in this range. In fact, restarting with
  mozregression --bad-rev=d5c1c2837d53 --good-rev=78a4540b0a9c --inbound

allows to go further.

Comment 1

[William Lachance (:wlach)]

Were you using the latest version of mozregression (0.24)? There were some fixes related to getting a sufficiently large inbound range in that release.

If you're still seeing the problem with that release, could you give the exact set of Y/N's to get down to that level?

Comment 2

[Mike Hommey [:glandium]]

$ mozregression --version
0.24

$ mozregression --bad=2014-10-17 --good=2014-08-30
afc933adf723 -> good
4b3d816c21fd -> good
f74ad36bb97b -> good
54217864bae9 -> good
62f0b771583c -> good
a280a03c9f3c -> bad
e1e2f5a56066 -> good
at this point we're out of nightlies and go to inbound
a280a03c9f3c -> bad (note this one was already tested, yet wanted again, but reading the log, it appears it wanted to test 91b1a62d1012d68d3e583b71b755b2a193c36d7a but actually used the previously downloaded file instead of downloading a new one ; it may have been confused by the version change)
bd068c8342fc -> good
ec600d4ffe61 -> good
3e08f81eed80 -> good
073e83cef238 -> good
beae97bde5ca -> good
47ac4791adf3 -> good
... and this time I'm not stopping at the same range:
No more inbounds to bisect
Last good revision: 47ac4791adf3
First bad revision: a280a03c9f3c
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=47ac4791adf3&tochange=a280a03c9f3c

Note how the boundary is the one that was tested twice.

Comment 3

[William Lachance (:wlach)]

That definitely sounds like a bug. I'll look into it.

Comment 5

[Elbart]

(In reply to Mike Hommey [:glandium] from comment #2)
> at this point we're out of nightlies and go to inbound
> a280a03c9f3c -> bad (note this one was already tested, yet wanted again, but
> reading the log, it appears it wanted to test
> 91b1a62d1012d68d3e583b71b755b2a193c36d7a but actually used the previously
> downloaded file instead of downloading a new one ; it may have been confused
> by the version change)
> bd068c8342fc -> good
> ec600d4ffe61 -> good
> 3e08f81eed80 -> good
> 073e83cef238 -> good
> beae97bde5ca -> good
> 47ac4791adf3 -> good
> ... and this time I'm not stopping at the same range:
> No more inbounds to bisect
> Last good revision: 47ac4791adf3
> First bad revision: a280a03c9f3c
> Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=47ac4791adf3&tochange=a280a03c9f3c
> 
> Note how the boundary is the one that was tested twice.

Sounds like a symptom of bug 1014140

Comment 6

[Julien Pagès (:parkouss)]

May be resolved with bug 1109731.

Comment 7

[Elbart]

(In reply to Julien Pagès from comment #6)
> May be resolved with bug 1109731.
It's already fixed in trunk, so no.

If I had to guess, it's probably the rewritten nightly-logic that fixed this.

In 0.30, the nightly-archive was still around when switching to inbound, and mozregression used it as the first inbound if the filenames matched (i.e. same version number).

In trunk, the archive seems to be deleted immediately once it's extracted, so when mozregression switches from Nightly to Inbound, there's no archive with the same filename, and mozreg is downloading the correct first Inbound-build.

Comment 8

[Julien Pagès (:parkouss)]

(In reply to Elbart from comment #7)
> If I had to guess, it's probably the rewritten nightly-logic that fixed this.

I think you are right Elbart. Maybe William want to look at it more in details, but I'm pretty sure also it is fixed now. We should close this bug as RESOLVED.

Comment 9

[Julien Pagès (:parkouss)]

(In reply to Elbart from comment #7)
> (In reply to Julien Pagès from comment #6)
> > May be resolved with bug 1109731.
> It's already fixed in trunk, so no.

I think we can close this one. It must works well with the most recent release 0.33. Will, I'm erasing your NI. :) If anybody can reproduce the bug, please reopen it.