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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-05-18 at 14:05 +0100, George Dunlap wrote:
> It sounds like you're saying just to have a "base Xen" build that would
> build what currently comes out of xen.git, and then base our other
> components on top of that.

Correct, otherwise you get one big job which can fail due to any
component, which makes reporting harder. It is nice to spot
ts-libvirt-build vs ts-xen-build failing in the reports rather than just
ts-raisin-build for everything.

More critically one big job makes the bisector less effective since it
has to rebuild things which haven't changed just because something which
shares the monolothic build job has changed. e.g. today a libvirt bisect
won't rebuild Xen if it doesn't have to.

> In which case what you described would probably work just fine.
> 
> >>> Per component dist dirs is similarly surely possible but perhaps not
> >>> something raisin wants.
> >>
> >> You could in theory have per-component "output" directories, and then a
> >> global "input" directory which was blown away at the beginning of every
> >> raisin build and re-constructed as needed.  That would be the sort of
> >> equivalent of the mock-style RPM build (where the chroot represents the
> >> global "input").
> >>
> >> Not sure how well that would work, though.
> > 
> > In essence everything builds into dist.$component and then at the end of
> > each component raisin automatically takes that and overlays whatever it
> > contains over some central dist.all which subsequent components actually
> > build against? Perhaps with a mode to seed dist.all from dist.* iff
> > dist.all doesn't exist.
> 
> Yeah, the basic idea would be when you run build, you rm -rf dist.all.
> Then if $dependency is in $COMPONENTS, then you clone (if necessary) &
> build; if not, you copy from dist.$dependency into dist.all.  If
> $dependency is neither in $COMPONENTS nor in dist.$dependency, you throw
> an error.
> 
> That solves the most general case; but it sounds like you care mostly
> about the very specific case of dealing with components that depend on
> the current output of xen.git.  Starting simple may be fine.

Currently we only have ts-*-build things which depend on the output of
ts-xen-build (in fact, we only have ts-libvirt-build).

I'm not sure if there will be others in the future, I suppose
ts-rump{qemu,xenstore,foo}-build -> ts-rumpkernel-build -> ts-xen-build
might eventually be a possibility...

Ian.


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