|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] OSSTEST: introduce a raisin build test
On Tue, 5 May 2015, Ian Campbell wrote:
> On Fri, 2015-04-24 at 16:46 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
>
> This looks like a good start, a few comments below.
>
> > diff --git a/ap-common b/ap-common
> > index 64749e3..985eeec 100644
> > --- a/ap-common
> > +++ b/ap-common
> > @@ -47,13 +47,18 @@
> > # 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}
>
> I suppose we should move this to a non-people location sooner rather
> than later.
Sure
> > diff --git a/mfi-common b/mfi-common
> > index 16fc8c5..051c9fc 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -215,6 +215,25 @@ create_build_jobs () {
> >
> > fi
> >
> > + if [ "x$REVISION_RAISIN" != xdisable ]; then
> > +
> > + ./cs-job-create $flight build-$arch-raisin build-raisin
> > \
> > + arch=$arch
> > \
> > + tree_xen=$TREE_XEN
> > \
> > + $RUNVARS $BUILD_RUNVARS $BUILD_RAISIN_RUNVARS
> > $arch_runvars \
> > + $suite_runvars
> > \
> > + host_hostflags=$build_hostflags
> > \
> > + buildjob=${bfi}build-$arch
> > \
> > + tree_raisin=$TREE_RAISIN
> > \
> > + tree_qemuu=$TREE_QEMU_UPSTREAM
> > \
> > + tree_qemu=$TREE_QEMU
> > \
> > + tree_seabios=$TREE_SEABIOS
> > \
> > + tree_libvirt=$TREE_LIBVIRT
> > \
> > + tree_ovmf=$TREE_OVMF
> > \
> > +
> > revision_raisin=${REVISION_RAISIN:-${DEFAULT_REVISION_RAISIN}}\
>
> I think you also need to pass revision_{xen,qemuu,qemu,libvirt,ovmf} etc
> and propagate them when you create the raisin config file instead of
> hardcoding a bunch of stuff in the ts- script.
OK, makes sense
> You should also call store_revision() for each git repo which was built
> so that it is recorded in the flight metadata.
All right.
> You should do this for
> _every_ git repo, not just ones which are explicitly set to a specific
> revision (osstest cares for bisection purposes what was built even if it
> cannot control that input tree).
That's fine as there is no hidden git cloning with raisin. All the trees
are specified explicitly in the config file.
> Lastly you will (eventually) need to divide the output into one or more
> component subtrees (e.g. ts-xen-build splits the hypervisor from the
> tools in order to support 32-on-64 configs) and call built_stash_file on
> them. Those then produce the outputs which other jobs can consume.
Raisin has the capability of installing and configuring stuff on the
host. I guess osstest wouldn't want to reuse that?
Also how is the separation supposed to be done? Given that osstest
requested raisin to build a certain number of components together,
raisin would put them all in the same deb package. From what you wrote I
take that ts-raisin-build should operate differently, but how?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |