cr-try-bisect: Use WAITSTART of when we started bisecting this testid

Otherwise bisection jobs get queued up very late.

The intent is that once we have a regression, we /start/ bisecting it
roughly FCFS along with other flights, but then it gets priority until
the bisection is done.

Then next bisection in the same branch will have to wait again, to
start.

We implement this by keeping a stamp file, whose timestamp shows when
we started bisecting this testid and this step.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff --git a/cr-try-bisect b/cr-try-bisect
index 2a5fe099cb034f8a693d91fb2dae64cbd4910274..c345ebd4b6f57e425483199ef6e9576e9fe7e2bb 100755 (executable)
--- a/cr-try-bisect
+++ b/cr-try-bisect
@@ -28,6 +28,7 @@ select_branch
 check_stop bisect.
 
 sticky=bisecting-sticky-branch
+startstamp=tmp/bisection-start-stamp
 
 anyflagfile=tmp/bisected-any.$branch
 
@@ -41,6 +42,7 @@ with-lock-ex -w $mrof.lock bash -xec "
 
 if ! test -f $mrof; then
         rm -f $sticky
+        rm -f $startstamp
         echo "$branch no mro"
         exit 0
 fi
@@ -75,7 +77,10 @@ compute_state_callback () {
 perhaps_bisect_step_core_testing_callback () {
 #        echo $branch >$sticky.new
 #        mv -f $sticky.new $sticky
-        export OSSTEST_RESOURCE_WAITSTART=`stat -c%Y $mrof`
+       printf "%s\n%s\n%s\n" $branch $job $testid >$startstamp.new
+       touch -r $mrof -m $startstamp.new
+       cmp $startstamp $startstamp.new || mv -f $startstamp.new $startstamp
+       export OSSTEST_RESOURCE_WAITSTART=`stat -c%Y $startstamp`
         OSSTEST_RESOURCE_WAITSTART=$(( $OSSTEST_RESOURCE_WAITSTART - 6000 ))
 }
 
@@ -99,6 +104,7 @@ while read keyword job testid basisflight; do
 done
 
 echo nothing to do
+rm -f $startstamp
 rm $mrof
 
 exit 0