Other-revision-jobs: Update cs-bisection-step

This is rather more subtle.  We want to be able to bisect over all the
relevant inputs.

What we actually want to do if one of the *prev* tests fail is to
treat the "previous Xen branch" as a separate "tree" when bisecting,
so each revision tuple has both "current" and "old" Xen versions.
That way if the stable-4.x branch has broken forward migration, we
will report it properly.

Indeed, this needs to be extended not just to the Xen revision, but
all the inputs to the *prev* build.

We achieve this with new concept `other-revision job suffix',
introduced in the previous patch.  The bisector now works internally
always with tree names which are `<tree>[ <suffix>]' (delimited by a
space).  (Henceforth, we'll call `[ <suffix>]' the `othrev'.)

That is, all the revisions specified in prev build jobs are treated as
revisions of different trees to the revisions of apparently-same trees
in non-prev jobs.

The specific changes needed to cs-bisection-step are very small.  We
only need to adjust the code which reads and writes the database:

* When we do the cross join on urls and revisions which generates the
  rev tuple for a particular flight, also have the database compute
  the othrev for each tree.  Then, print the othrev in the debug
  output, and append it to the tree name.

  That resulting name is used everywhere:

  It affects `mixed revision' detection, so we consider build-*-prev
  jobs with differing revisions to problematic, or main-revision build
  jobs with differing revisions, but we treat each category of build
  job separately so the fact that the prev and main build jobs have
  different revisions is fine.

  The name is used for the key that is returned from flight_rmap.
  Thence it is used for the Name in @treeinfos, and therefore the
  results from flight_rtuple will be terms of this decorated tree
  namespace.

* When we are preparing a new job to go, we need to (effectively) undo
  this transformation.  The query which finds the `tree_' variables
  for a particular tree name is arranged to take an additional
  parameter, which is the othrev.  If the othrev does not match the
  job, the name is not returned in the results.

  Actually, because both the job and the othrev are query parameters,
  what happens is either that they match (ie, the othrev in the tree
  name from @treeinfos is indeed the othrev for the job we are
  constructing) in which case we process the variable as before; or
  they don't match, in which case the query contains contradictory
  conditions in its AND clauses, and returns no rows.

  So the ultimate effect is that we process each Name from @treeinfos
  only if it is for the this kind of job.  This slightly convoluted
  implementation arises from the fact that the job-to-othrev mapping
  is implemented as SQL, so we need to ask the database.

There is no need to change any of the output processing and reporting,
because "<tree> prev" is a perfectly good thing to print in all the
relevant contexts.

And there is no need to change how we drive adhoc-revtuple-generator,
because we do not pass it tree names at all, only urls.

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

diff --git a/cs-bisection-step b/cs-bisection-step
index 57ecac4a042e78655e7bc2f7c619ef8ecb9498a8..42bf20ba2a37bae989ee662e93556d59640280e2 100755 (executable)
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -108,7 +108,7 @@ our ($branch,$job,$testid) = @ARGV;
 
 our ($latest_flight, $hosts, $basispass_flight);
 our (@treeinfos);
-# $treeinfos[]{Name}
+# $treeinfos[]{Name}     Name might be  "<treename> <other-job-revision-spec>"
 # $treeinfos[]{Url}
 
 our $restrictflight_cond= restrictflight_cond();
@@ -208,6 +208,7 @@ END
         SELECT url.val AS uval,
               rev.val AS rval,
               url.job AS job,
+               ${\ other_revision_job_suffix('url.job',' ') } AS othrev,
               url.name AS longname
 
            FROM tmp_build_info AS rev
@@ -232,7 +233,8 @@ END
         $row->{longname} =~ m/^tree_/ or die "$row->{longname} ?";
         my $name= $'; #'
         print DEBUG " $flight.$row->{job} uval=$row->{uval}".
-            " rval=$row->{rval} name=$name\n";
+            " rval=$row->{rval} name=$name othrev=\`$row->{othrev}'\n";
+       $name .= $row->{othrev};
         my $rev= $row->{rval};
         next unless length $rev;
         $rev =~ s/\+//g;
@@ -1069,14 +1071,21 @@ END
         SELECT name FROM runvars
           WHERE  flight=? AND job=?
             AND  name = ?
+            AND  ${\ other_revision_job_suffix('job',' ') } = ?
 END
     foreach (my $i=0; $i<@treeinfos; $i++) {
         my $name= $treeinfos[$i]{Name};
+       my $othrev = $name =~ s{ (.+)$}{} ? $1 : '';
         my $treevar= 'tree_'.$name;
-        $treeq->execute($copyflight, $popjob, $treevar);
+        $treeq->execute($copyflight, $popjob, $treevar, $othrev);
         my ($treerow) = $treeq->fetchrow_array();
         $treeq->finish();
         next unless defined $treerow;
+       # Effect of the check on other_revison_job_suffix is that
+       # we don't see a runvar row if the othrev from the treeinfo
+       # does not correspond to that of the job - ie, the treeinfo
+       # does not apply to this job.
+
         my $revname= "revision_$name";
         my $revval= $trevisions[$i];