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