New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 592691 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 593055
Owner: ----
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature



Sign in to add a comment

Bisect should early out if it reproduces a failure for return code bisects.

Project Member Reported by simonhatch@chromium.org, Mar 7 2016

Issue description

https://build.chromium.org/p/tryserver.chromium.perf/builders/android_one_perf_bisect/builds/1192

Might be reading this wrong, but I was trying to bisect on return code. I think the old script would early out as soon as any run failed if it was bisecting on return code, whereas this seems to continue and run every iteration.
 
Summary: Bisect should early out if it reproduces a failure for return code bisects. (was: Bisect should early out if it reproduces a failure.)
Cc: dtu@chromium.org
Labels: -Type-Bug triaged Type-Feature
Status: Available (was: Untriaged)
I think it makes sense to treat return code bisects specially, as long as we're assuming that at least one failure means it should be classified as "bad".

But, if possible, it may be good to keep the logic/process for return-code and perf result bisects as similar/simple as possible.

Anyone have any other thoughts about this?
I feel this is a dup of 593055, because current bisect by default runs tests for 5 time for either of the cases (perf or return_code). If we fix 593055 for return_code then I don't think it will continue on failures.
If you user specifies >1 repeat_count then bisect should continue even after the failure.

Comment 4 by dtu@chromium.org, Mar 17 2016

Mergedinto: 593055
Status: Duplicate (was: Available)
Sure.
How about flakey failures? You'd still early out after reproducing just 1.
Components: Speed>Bisection

Sign in to add a comment