Closed
Bug 1210013
Opened 9 years ago
Closed 9 years ago
Add ability to bisect directly on an integration branch
Categories
(Testing :: mozregression, defect)
Testing
mozregression
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: RyanVM, Assigned: parkouss)
References
Details
Attachments
(1 file)
Today I found myself wanting to re-bisect a bug directly on fx-team but was unable to find a way to do so. I tried |mozregression --repo fx-team --good XXX --bad YYY| but it errored out not being able to find a suitable nightly. I ended up working around it by spoonfeeding it a one-day good and bad date for m-c, but it would be nice if I could go straight to fx-team without having to do that.
Feel free to WONTFIX this if I'm doing it wrong :)
Comment 1•9 years ago
|
||
This *should* work, I think? :parkouss?
Assignee | ||
Comment 2•9 years ago
|
||
Well, yes it should - but the command has to be:
mozregression --inbound-branch fx-team --good-changeset XXX --bad-changeset YYY
And you should use changesets instead of dates.
Well I'm thinking more and more we should try to get rid of this distinction: nightly (--repo, using dates) / inbound (--inbound-branch, using changesets).
Ryan, please tell me if that workaround is ok for now.
Reporter | ||
Comment 3•9 years ago
|
||
(In reply to Julien Pagès (:parkouss) from comment #2)
> Well, yes it should - but the command has to be:
>
> mozregression --inbound-branch fx-team --good-changeset XXX --bad-changeset
> YYY
>
> And you should use changesets instead of dates.
Whoops :). Maybe we can catch this incorrect usage and spit out a more informative error message?
> Well I'm thinking more and more we should try to get rid of this
> distinction: nightly (--repo, using dates) / inbound (--inbound-branch,
> using changesets).
Yeah, thinking about it more, I can see the problem with trying to bisect by date on an integration branch where nightlies don't exist. Though maybe we could default to grabbing the first push of the day per the pushlog for the beginning of the range and the last push of the day for the end of the range in such a circumstance?
To add more context, the issue I ran into that caused me to get into this situation was that I was bisecting a failure on inbound and the final range was clearly pointing at a merge commit as the culprit. As far as I can tell, there's no good way to then tell mozregression to basically restart inbound branch bisection on a different branch instead, like |mozregression --resume --inbound-branch fx-team| or something. It's a bit cumbersome to go through the bisection logs to come up with the parameters needed to feed the new run in such a way as to avoid redundant work.
Assignee | ||
Comment 4•9 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #3)
> (In reply to Julien Pagès (:parkouss) from comment #2)
> > Well I'm thinking more and more we should try to get rid of this
> > distinction: nightly (--repo, using dates) / inbound (--inbound-branch,
> > using changesets).
So this has been done with bug 1095058. :) only --repo will exist now (in upcoming mozreg release).
> Yeah, thinking about it more, I can see the problem with trying to bisect by
> date on an integration branch where nightlies don't exist. Though maybe we
> could default to grabbing the first push of the day per the pushlog for the
> beginning of the range and the last push of the day for the end of the range
> in such a circumstance?
This is exactly what this patch do. :) So we will be able to do it with the command you used, e.g |mozregression --repo fx-team --good XXX --bad YYY|. Changesets will still be usage with --goo-rev/--bad-rev.
Comment 5•9 years ago
|
||
Comment on attachment 8692681 [details] [review]
allow to use dates with integration branches
LGTM!
Attachment #8692681 -
Flags: review?(wlachance) → review+
Assignee | ||
Comment 6•9 years ago
|
||
Thanks Will!
Landed in https://github.com/mozilla/mozregression/commit/76104b84578b69c966e6455d8abba0f82d16772f.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•