tcwg_kernel-bisect.sh: Improve handling of git-bisect edge cases

Move code for handling "last_good" revision to a better place,
and re-trigger bisect to find true first_bad commits.

Change-Id: I29ee1ef7c287dc9baa6f909142eb57e344cda523

1 files changed, 39 insertions, 27 deletions

diff --git a/tcwg_kernel-bisect.sh b/tcwg_kernel-bisect.sh
index 5b913c4d..e3783f06 100755
--- a/tcwg_kernel-bisect.sh
+++ b/tcwg_kernel-bisect.sh
@@ -201,12 +201,51 @@ res=0 && wait $! || res=$?
 if [ x"$res" = x"0" ]; then
     first_bad=$(cat .git/BISECT_RUN | head -n 1 | grep "is the first bad commit" | cut -d" " -f 1)
     assert [ x"$first_bad" != x"" ]
+
+    last_good=$(git rev-parse $first_bad^)
+    if ! grep -q $last_good "$artifacts/good_revs"; then
+	# It seems that git-bisect assumes parent commit as "good" on
+	# the basis of one of its children being "good".  Therefore we
+	# can have a situation when we have parent P with children C1 and C2,
+	# and child C1 has a child of its own CB.  Git-bisect tests C2 as
+	# "good", and CB as "bad".  From C2 being good it assumes P as "good",
+	# and it knows CB is "bad", so git-bisect returns C1 as the first bad
+	# commit.
+	# To simplify investigations we explicitly test parent of $first_bad.
+	echo "Testing last_good $last_good (hoping for success)"
+	git checkout --detach "$last_good"
+	$artifacts/test.sh &
+	res=0 && wait $! || res=$?
+	if [ x"$res" != x"0" ]; then
+	    # It seems $last_good was on a path that tested good, even though
+	    # it itself is bad.  We re-trigger the bisection job with updated
+	    # parameters.
+	    # We need to be careful to avoid re-trigger loops, so verify that
+	    # last_good is an ancestor of bad_rev.
+	    assert [ x"$(git rev-list $last_good ^$bad_rev)" = x"" ]
+	    cat > $artifacts/trigger-0-bisect-again <<EOF
+current_project=$current_project
+baseline_rev=$baseline_rev
+bad_rev=$last_good
+EOF
+	    # Don't send any emails.
+	    echo > $artifacts/jenkins/mail-recipients.txt
+	    touch $artifacts/jenkins/build-name
+	    sed -i -e "s/\$/-retry/" $artifacts/jenkins/build-name
+	    trap "" EXIT
+	    exit 0
+	fi
+    fi
+
     echo $first_bad > $artifacts/first-bad
 else
     first_bad=$(git rev-parse HEAD)
     if ! [ -f .git/BISECT_LOG ]; then
 	# It seems this was a trivial bisect with $bad_rev^ == $good_rev.
 	first_bad=$bad_rev
+	last_good=$(git rev-parse $first_bad^)
+	assert [ x"$last_good" = x"$good_rev" ]
+
 	echo $first_bad > $artifacts/first-bad
     fi
 fi
@@ -237,38 +276,11 @@ if [ -f $artifacts/first-bad ]; then
     ln -f -s "build-$first_bad" "$artifacts/build-first_bad"
     ln -f -s "build-$first_bad.sh" "$artifacts/manifests/build-first_bad.sh"
 
-    last_good=$(git -C $current_project rev-parse $first_bad^)
-
     good_name="last_good"
     good_sha1="$last_good"
     bad_name="first_bad"
     bad_sha1="$first_bad"
 
-    if ! grep -q $last_good "$artifacts/good_revs"; then
-	# It seems that git-bisect assumes parent commit as "good" on
-	# the basis of one of its children being "good".  Therefore we
-	# can have a situation when we have parent P with children C1 and C2,
-	# and child C1 has a child of its own CB.  Git-bisect tests C2 as
-	# "good", and CB as "bad".  From C2 being good it assumes P as "good",
-	# and it knows CB is "bad", so git-bisect returns C1 as the first bad
-	# commit.
-	# To simplify investigations we explicitly test parent of $first_bad.
-	cd $current_project
-	echo "Testing last_good $last_good (hoping for success)"
-	git checkout --detach "$last_good"
-	$artifacts/test.sh &
-	res=0 && wait $! || res=$?
-	if [ x"$res" != x"0" ]; then
-	    # It seems $last_good was on a path that tested good, even though
-	    # it itself is bad.  Not much we can do here -- fallback to $good_rev.
-	    echo "WARNING: build for last_good $last_good failed"
-	    last_good="$good_rev"
-	    good_name="good_rev"
-	    good_sha1="$good_rev"
-	fi
-	cd ..
-    fi
-
     ln -f -s "build-$last_good" "$artifacts/build-last_good"
     ln -f -s "build-$last_good.sh" "$artifacts/manifests/build-last_good.sh"