sg-report-flight: Actually look at retest flights (part 2)

To avoid going down ratholes (especially for jobs which reuse outputs
from their previous selves), the primary flight/job finder in
sg-report-flight does not recurse indefinitely through build jobs.
Instead, it restricts the build jobs investigated to those within the
same flight as the job which might be of interest.

As a result, retest jobs are, unfortunately, discarded at this stage
because we insist that the build jobs we find did use the tree
revision we are investigating.

Fix this by recursing into the corresponding primary flight too.
In the $flightsq->fetchrow loop that's $xflight.

For the primary flight, ie the first half of the UNION, that's just
the fligth itself.  So there this has no change.

For the retest flights, it is the flight that all the build jobs refer
to.  Despite the CROSS JOIN, this will be unique for any particular
"retest flight", because the query on the runvars insists that all of
the (at least some) buildjob runvars for f1 point to f0.  Ie, f1 has
no build jobs and refers to f0 for build jobs; so it can't refer to
any other f0' in the cross join.

With this change, a -retest flight can now actually be used to justify
a push.

Signed-off-by: Ian Jackson <iwj@xenproject.org>

diff --git a/sg-report-flight b/sg-report-flight
index 70cad23079b98fe069ff3c2e7f8398f4a088db8f..7f0543ffb1465618c66fe7ffc28973076abd1cf4 100755 (executable)
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -334,9 +334,12 @@ $runvars_conds
             LIMIT 1000
       ),
       retest_flights AS (
-        SELECT DISTINCT f1.flight flight, f1.blessing blessing
+        SELECT DISTINCT 
+                  f1.flight flight,
+                  f0.flight xflight,
+                  f1.blessing blessing
              FROM flights f1
-             JOIN jobs j USING (flight) 
+             JOIN jobs j USING (flight)
        CROSS JOIN relevant_flights f0
             WHERE ($cmdline_flight_cond)
               AND (
@@ -348,10 +351,10 @@ $runvars_conds
                   AND r.name LIKE '%buildjob'
                   )
       )
-      SELECT flight, jobs.status
+      SELECT flight, xflight, jobs.status
         FROM (
-           SELECT * FROM relevant_flights
-     UNION SELECT * FROM retest_flights
+ SELECT        flight, flight xflight, blessing FROM relevant_flights
+ UNION SELECT  flight,        xflight, blessing FROM retest_flights
              ) all_relevant_flights
 $flightsq_jobs_join
        WHERE (1=1)
@@ -392,7 +395,7 @@ END
                 WHERE flight=?
 END
 
-    while (my ($tflight, $tjstatus) = $flightsq->fetchrow_array) {
+    while (my ($tflight, $xflight, $tjstatus) = $flightsq->fetchrow_array) {
        # Recurse from the starting flight looking for relevant build
        # jobs.  We start with all jobs in $tflight, and for each job
        # we also process any other jobs it refers to in *buildjob runvars.
@@ -408,6 +411,11 @@ END
        # actually interested in (ii) the kind of continuous update
        # thing seen with freebsdbuildjob.
        #
+       # However, when we are looking at a retest flight (offered to
+       # us with --refer-to-flights, or found because it was
+       # specified on the command line) we look at its build flight;
+       # that's what $xflight is;
+       #
        # (This is rather different to cs-bisection-step, which is
        # less focused on changes in a particular set of trees.)
        #
@@ -435,7 +443,7 @@ END
        while (@binfos_todo) {
            my ($why,$bflight,$bjob) = @{ shift @binfos_todo };
            next if $binfos{$bflight}{$bjob};
-            next unless $bflight == $tflight;
+            next unless $bflight == $tflight || $bflight == $xflight;
            $binfos{$bflight}{$bjob} = $why;
            $buildjobsq->execute($bflight,$bjob);
            $binfos_queue->($bflight,$buildjobsq,$why);