Open Bug 1487262 Opened 2 years ago Updated 2 years ago

mozregression only outputs the topmost commit in a push.

Categories

(Testing :: mozregression, defect)

Unspecified
Windows
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: aklotz, Unassigned)

Details

I'm running mozregression against mozilla-inbound for Windows opt 64-bit Firefox.

I know that revision a3b77a00 is the last good one. b4811b88 is the first bad one. According to hg.mozilla.org, there is one revision in between, ca936adbc565.

Using a larger initial range, mozregression never "sees" ca936adbc565.
If I start a new bisection using [a3b77a00, b4811b88] as the bounds, mozregression fails with this error:

platform: Windows-10-10.0.17134
python: 2.7.15 FROZEN (32bit)
mozregui: 0.9.28
mozregression: 2.3.31
message: IndexError: list index out of range
traceback:   File ".\mozregui\report.py", line 276, in finished


I really need to know whether ca936adbc565 is good or bad, so it would be nice if mozregression could actually find it!
Flags: needinfo?(wlachance)
Hmm, it looks like the reason why it can't do it is because ca936adbc565 was part of the same push.

mozregression only outputs the message from the topmost commit in the push. Could we maybe improve the logging output to include all of the commit messages in the push?
No longer blocks: 1483963
Summary: mozregression seemingly is missing a revision during bisection. → mozregression only outputs the topmost commit in a push.
(In reply to Aaron Klotz [:aklotz] from comment #1)
> Hmm, it looks like the reason why it can't do it is because ca936adbc565 was
> part of the same push.

As b4811b88, that is.
Seems like something that we could improve. Can you include a console log of what you're seeing and what you would prefer to see instead?
Flags: needinfo?(wlachance) → needinfo?(aklotz)
2018-08-29T16:15:34: INFO : Narrowed inbound regression window from [a3b77a00, b4811b88] (3 builds) to [a3b77a00, b5f6cc47] (2 builds) (~1 steps left)
2018-08-29T16:15:34: DEBUG : Starting merge handling...
2018-08-29T16:15:34: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=b5f6cc47313dfd024408e6c8f74555410638e3cb&full=1
2018-08-29T16:15:34: DEBUG : Found commit message:
Bug 1469523 - Remove unused methods from nsAttrAndChildArray, r=smaug

2018-08-29T16:15:34: DEBUG : Did not find a branch, checking all integration branches
2018-08-29T16:15:34: INFO : The bisection is done.
2018-08-29T16:15:34: INFO : Stopped

If we look at that revision in treeherder:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=b5f6cc47313dfd024408e6c8f74555410638e3cb

We see that there was a second commit from a distinct bug in that push. So what I'd like to see is output of a commit message for each distinct bug. Something like:

2018-08-29T16:15:34: DEBUG : Found commit messages:
Bug 1469523 - Remove unused methods from nsAttrAndChildArray, r=smaug
Bug 1469521 - Change storage of previous and next children in nsINode, r=bz
Flags: needinfo?(aklotz)
(When I was bisecting, the sole commit that was displayed by mozregression could not have been responsible for the regression, so having additional debug messages about what else was in the push would have been useful.)
You need to log in before you can comment on or make changes to this bug.