cs-bisection-step ignores any flight with broken steps, on the grounds
that the results in such a flight maybe unreliable.
Therefore, if a main flight has both broken steps and regressions, it
is wrong to take its mro as the new basis mro for bisections. In the
worst case a newly failing job will be determined to be unbisectable
(since the only relevant failure is in a broken flight), have the
stamp file created, and then never be properly bisected.
So: in sg-report-flight, report `broken-step' for each broken step (in
the top-level flight we are reporting - broken jobs in flights we are
referring to to justify heisenbugs are OK); and, in cr-daily-branch,
do not install the new mro if such indications are present.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
if grep -xF $NEW_REVISION $branch.force-rev; then push=$OSSTEST_PUSH; fi
if test -f $branch.block; then push=false; fi
-if test -e $mrof && test -e $tree_bisect; then
+if test -e $mrof && test -e $tree_bisect && ! grep '^broken' $mrof; then
with-lock-ex -w $tree_bisect/$mrof.lock bash -xec "
rm -f $tree_bisect/$mrof.in.new
cp $mrof $tree_bisect/$mrof.in.new
$failv->{Blocker}= '';
next;
}
+
+ if ($st eq 'broken' && !$heisen_why) {
+ print MRO "broken-step $s->{job} $s->{testid}\n";
+ }
+
if (!($st eq 'fail' or $st eq 'broken')) {
print MRO "broken $j->{job} $s->{testid} $st\n";
print DEBUG " not a fail, unjustifiable\n";