Re: [Xen-devel] [PATCH v2 9/9] make-flight/mfi-common: Add livepatch build/test target in the matrix.

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("Re: [Xen-devel] [PATCH v2 9/9] make-flight/mfi-common: Add 
livepatch build/test target in the matrix."):
> I think you need to filter this test case to only run for 4.7+.
> 
> There is no point in running it for older releases.

There are basically two plausible approaches to this:

1. Set up the job for all branches, including old ones, and arrange for
  the new job to fail early ("fail never pass") before host
  allocation.  That would waste minimal time etc.

2. Arrange to set up the job only on branches where attempting it is
  worthly.

I had been suggesting to Konrad that he should do 2.  There are
reasons to prefer both options.  (1) is simpler in make-flight etc.;
(2) clutters the test reports (and database tables) with complaints
about unimplemented features.

Looking at Konrad actual patches and at the current code:

The "thing not built, do not run test" logic is as follows:

  - sg-run-job runs `ts-build-check' (in the proc
    `check-not-blocked') before host allocation and setup

  - ts-build-check iterates over all things referred to
    by runvars of the form [IDENT_]PARTbuildjob.  It then
    looks inside those for the dist PART (ie the
    runvar path_PARTdist).

In Konrad's new code,

  - The xlptest output is only stashed if it was generated by the
    build.  This is correct.

  - However, the test jobs refer to the build jobs via the
    `xenbuildjob' runvar.  This does not match the use pattern
    expected by ts-build-chedk, which would be to look for
    `xlptestbuildjob'.

I think this latter point should be fixed (by adding that runvar to
the test cases and having ts-livepatch-install refer to it).  Then I
think Konrad or I could usefully run an ad-hoc flight on an old Xen
branch and check that it DTRT.

This would implement option (1) above.  I would not object to
implementing option (2) as well, which would be just a matter of
making this case statement a bit more sophisticated.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel