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

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-05-12 at 12:20 +0100, Stefano Stabellini wrote:

> > 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" ] ?

That isn't necessary now. I was thinking about the future when we may
want to switch to raisin for building everything (i.e. removing the
current build jobs).

> > 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.

I don't think we can install Xen, since this will be a potentially
shared build host.

> > 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.

Would a separate clone of the same raisin version with some sort of
"dist" directory transported over be sufficient and supportable? Or are
raisin's outputs not in one place and easily transportable?

i.e. today build-$ARCH-libvirt picks up the dist.tar.gz files from the
corresponding build-$ARCH, unpacks them and asks libvirt to build
against that tree.

Ian.