Re: [Xen-devel] [PATCH v4] OSSTEST: introduce a raisin build test

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 12 May 2015, Ian Campbell wrote:
> On Tue, 2015-05-12 at 10:20 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > 
> > ---
> > 
> > Changes in v4:
> > - introduce enable_raisin in mfi-common: only build raisin when building
> > xen-unstable
> > - start off from the default raisin config, then append osstest config
> > options to it
> > - do not write variable to the raisin config if the conrresponding
> > runvar is not set
> > - remove TREE_OVMF and TREE_SEABIOS
> > 
> > Changes in v3:
> > - use $raisindir throughout ts-raisin-build
> > - do not specify ENABLED_COMPONENTS so that empty REVISION variables can
> > be used to disable building a raisin component
> > 
> > Changes in v2:
> > - set revision_* variables in mfi-common;
> > - in ts-raisin-build set the *_REVISION config options based on the
> >   revision_* variables;
> > - in ts-raisin-build, call store_revision appropriately;
> > - divide the output in an hypervisor and a tools tarball.
> > ---
> >  ap-common       |    3 +
> >  mfi-common      |   36 +++++++++++
> >  sg-run-job      |    5 ++
> >  ts-raisin-build |  186 
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 230 insertions(+)
> >  create mode 100755 ts-raisin-build
> > 
> > diff --git a/ap-common b/ap-common
> > index 64749e3..f8c02a7 100644
> > --- a/ap-common
> > +++ b/ap-common
> > @@ -47,6 +47,9 @@
> >  # rumpsrc-related runvars needed only for old rumpuser-xen
> >  # (ie ones which need $bodges=1 in ts-rumpuserxen-build)
> >  
> > +: ${TREE_RAISIN:=git://xenbits.xen.org/people/sstabellini/raisin.git}
> > +: ${DEFAULT_REVISION_RAISIN:=master}
> 
> If master is what you get if you just do git clone URL then I think you
> can omit this and its usage in mfi-common, build_clone will see the
> empty revision_xen and accept the default from the clone.

OK


> Otherwise I think this script, together with the corresponding raisin
> change does the right thing.
> 
> The next step towards having this actually used by the automated tests
> would be to add cases for raisin to ap-fetch-version and
> ap-fetch-version-old. Those should return the "new version of raisin to
> be tested" and "the already tested version of raisin for other branches
> to use" respectively.
> 
> Then you need to add some code to cr-daily-branch which calls
> "determine_version REVISION_RAISIN raisin RAISIN" if REVISION_RAISIN is
> not set, e.g. like it does for libvirt.
> 
> That should be enough to get xen-unstable flights doing something useful
> with this new test case, I think.
> 
> You can more closely emulate the automated environment by using
> cr-daily-branch instead of make-flight directly. The easiest way is to
> use the helper script. e.g.
> 
>         ./standalone make-flight xen-unstable
> 
> Use -f NAME to name the flight something other than "standalone", which
> can be useful if you want to generate and compare multiple flights.
> 
> Have you seen ./mg-show-flight-runvars <FLIGHT_NAME>? It shows you the
> result of make-flight.
> 
> A few thoughts:
> 
> We currently have build jobs for both normal and the XSM case.
> Duplicating the raisin jobs is also going to duplicate the build for
> everything else it builds, which might be wasteful?

We could disable the raisin build if [ enable_xsm = "true" ] ?


> More generally this now ties everything together into one build job.
> Currently while bisecting osstest can try and reuse e.g. the xen job
> with a different libvirt build, which saves some time. I think this is
> an unavoidable consequence of how raisin is designed to work and we'll
> just have to suck it up.

It is possible to just build xen first and libvirt later, as long as you
reuse the same raisin environment, or you install xen on the system
first.


> The only alternative I can see would be for raisin to have an
> "incremental" mode where it can be pointed at the results of a previous
> raisin build and build additional components based on that. I suspect
> you don't want this complexity in raisin though.

I don't want to support the case where raisin is asked to build a
component based on a previous raisin build at an alternative location.
But building Xen first, then going back to the same raisin directory and
building libvirt later is fine.


> > diff --git a/mfi-common b/mfi-common
> > index 16fc8c5..eebad34 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -148,6 +148,17 @@ create_build_jobs () {
> >      *) enable_ovmf=true;
> >      esac
> >  
> > +    case "$xenbranch" in
> > +    xen-3.*-testing) enable_raisin=false;;
> > +    xen-4.0-testing) enable_raisin=false;;
> > +    xen-4.1-testing) enable_raisin=false;;
> > +    xen-4.2-testing) enable_raisin=false;;
> > +    xen-4.3-testing) enable_raisin=false;;
> > +    xen-4.4-testing) enable_raisin=false;;
> > +    xen-4.5-testing) enable_raisin=false;;
> > +    *)               enable_raisin=true;
> 
> Hr, $xenbranch==xen-unstable for a bunch of other flights too, e.g. ovmf
> and seabios.
> 
> Eventually this is what we would want, but for now might it be better to
> test $branch so we test exactly with the xen-unstable flight?
> 
> ($branch == the actual thing under test, $xenbranch == the version of
> Xen to use when testing $branch, which may differ if $branch is not a
> Xen of some sort)

OK

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