round-robin-bisect.sh: Make handling of unsuccessful bisects more robust

Now we either advance baseline to a more recent commits, which
helps with benchmarking tracking, which can have "skipped" commits
due to problems with benchmarking infra, or we reset baseline to
the last-tested bad commit (which was, in essence, previous behavior).

Change-Id: I9eaa473504d33e5af4dfa4500578110bddfb35f9

1 files changed, 41 insertions, 6 deletions

diff --git a/round-robin-bisect.sh b/round-robin-bisect.sh
index fb702166..3e2aee39 100755
--- a/round-robin-bisect.sh
+++ b/round-robin-bisect.sh
@@ -449,12 +449,47 @@ EOF
 	exit 0
     fi
 else
-    # When "git bisect run" fails, e.g., due to merge-base of $baseline_rev and
-    # $bad_rev is worse than $baseline_rev, we want to reset baseline to HEAD,
-    # so that we catch most of the commits that introduced change in the result
-    # metric.
-    first_bad=$(git rev-parse HEAD)
-    push_interesting_commit $first_bad "bad-merge-base"
+    # "Git bisect" didn't find the first_bad commit.
+    # Possible reasons include:
+    # - We have marked the regressing commit as "skip", which can happen
+    #   to tcwg_bmk* projects when benchmarking infra has a problem.
+    #
+    # - Merge-base of $baseline_rev and $bad_rev is worse than $baseline_rev.
+    #   We want to reset baseline to HEAD in this case, so that we catch most
+    #   of the commits that introduced change in the result metric.
+    #
+    # So, to make at least some progress on narrowing down the regression ...
+    # - look for the last commit that tested "good".  If it's not $baseline_rev,
+    #   then we have narrowed down the bisection range somewhat.  Therefore,
+    #   trigger two builds:
+    #   - one to ADVANCE baseline to the last GOOD commit, and
+    #   - another to expose the regression again.
+    #
+    # - If $baseline_rev is the only good commit, then we have got outselves
+    #   to a tricky situation: we can't find the regression, and can't make
+    #   a good build, which would advance the baseline.  To resolve this,
+    #   trigger two builds:
+    #   - one to RESET baseline to the last BAD commit, and
+    #   - another to advance the baseline and expose another regression.
+    #   Note that this approach correctly handles case when merge-base of
+    #   $baseline_rev and $bad_rev tests "bad".
+
+    last_good=$(print_tested_revs good | tail -n1)
+    assert_with_msg "We should have at least baseline_rev as a good commit" \
+		    [ x"$last_good" != x"" ]
+
+    if [ x"$last_good" != x"$baseline_rev" ]; then
+	cat > $artifacts/trigger-build-1-advance <<EOF
+${current_project}_url=$bad_url
+${current_project}_branch=$last_good
+EOF
+	sed -i -e "s/\$/-advance-baseline/" $artifacts/jenkins/build-name
+    else
+	first_bad=$(print_tested_revs bad | tail -n1)
+	sed -i -e "s/\$/-reset-baseline/" $artifacts/jenkins/build-name
+    fi
+    # Don't send any emails.
+    notify_devs=false
 fi
 
 # Bisect if officially over.