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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-05-11 at 15:44 +0100, Stefano Stabellini wrote:

> > > 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       |    5 ++
> > >  mfi-common      |   25 +++++++++
> > >  sg-run-job      |    5 ++
> > >  ts-raisin-build |  161 
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >  4 files changed, 196 insertions(+)
> > >  create mode 100755 ts-raisin-build
> > > 
> > > 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}
> > > +: ${DEFAULT_REVISION_RAISIN:=master}
> > > +
> > >  : ${TREE_SEABIOS_UPSTREAM:=git://git.seabios.org/seabios.git}
> > >  : ${PUSH_TREE_SEABIOS:=$XENBITS:/home/xen/git/osstest/seabios.git}
> > >  : ${BASE_TREE_SEABIOS:=git://xenbits.xen.org/osstest/seabios.git}
> > > +: ${TREE_SEABIOS:=$TREE_SEABIOS_UPSTREAM}
> > >  
> > >  : ${TREE_OVMF_UPSTREAM:=https://github.com/tianocore/edk2.git}
> > >  : ${PUSH_TREE_OVMF:=$XENBITS:/home/xen/git/osstest/ovmf.git}
> > >  : ${BASE_TREE_OVMF:=git://xenbits.xen.org/osstest/ovmf.git}
> > > +: ${TREE_OVMF:=$TREE_OVMF_UPSTREAM}
> > 
> > What are these two doing? If it's something legitimate then it really
> > needs to be mentioned in the commit log, but using
> > git://git.seabios.org/seabios.git here seems wrong, and I think we
> > change things for older branches and the existing ts-xen-build job.
> 
> I thought it was wrong that all the other components provide a TREE_
> variable, but OVMF and SEABIOS. Running in stand-alone mode, their
> absence would break raisin compilation. From a look at mfi-common, it
> seems to me that other jobs could break too for the same reason.

OVMF and SeaBIOS are indeed a bit of a strange special case, mainly
because they do not get the full push gate treatment yes.

But those other jobs succeed because xen.git:Config.mk will provide any
missing things, by pointing at the version used in that release.

By changing things like you have you have just changed the behaviour of
those jobs from using Config.mk (pointing at xenbits) to using the
upstream trees for SeaBIOS and OVMF, for all jobs other than the seabios
and ovmf ones, we certainly don't want that.

> > I have a feeling that these relate to trees which we previously allowed
> > xen.git:Config.mk to choose, which means we need to have a little think
> > about the behaviour of cr-daily-branch vs this script here.
> > 
> > Perhaps you should do for TREE_{SEABIOS,OVMF} as you have done for the
> > revision, i.e. use ${TREE_SEABIOS:-<SOMEDEFAULT>}
> >
> > Where <SOMEDEFAULT> is whatever is in xen.git Config.mk today.
> 
> Yes, that would work too. Do you mean here, or under ./cs-job-create in
> mfi-common?

mfi-common I think, but see below.

> > Or maybe raisin has some way to say "whatever you think is best"?
> > 
> > The question here is, I suppose, where should the replacement for the
> > Config.mk supplied defaults live now, in osstest.git or raisin.git?
> 
> The defaults are available in raisin to users via the default config
> (see defconfig), that we are not using because we want to pass specific
> settings to raisin, in particular we want to specify a REVISION for
> each component. As we are down to this level of control, it seems
> natural to me to also specify the trees we want to use.

The problem is that today there are some trees (seabios + ovmf) where we
do not use that level of control and rely on xen.git:Config.mk.

Perhaps the right answer is to append osstest's requests to the rasin
defconfig?

IOW in the absence of being told otherwise we should be building
whatever raisin would normally build here.

Where in the raisin world would a commit such as
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=6dacedd707c20212006e4e100443aa8cc8997d8c
 go? Would it be a commit to raisin's defconfig? Or does raisin always use 
master? That is a development version of SeaBIOS, not a release.

Ian.


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