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

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

On Wed, 2015-05-06 at 17:02 +0100, Stefano Stabellini wrote:
> On Wed, 6 May 2015, Ian Campbell wrote:
> > On Wed, 2015-05-06 at 15:43 +0100, Stefano Stabellini wrote:
> > [...]
> > > +    echo >>config ENABLED_COMPONENTS=\\"seabios ovmf xen qemu qemu_traditional libvirt\\"
> > [...]
> > > +    echo >>config XEN_URL=\\"$r{tree_xen}\\"
> > > +    echo >>config QEMU_URL=\\"$r{tree_qemuu}\\"
> > > +    echo >>config QEMU_TRADITIONAL_URL=\\"$r{tree_qemu}\\"
> > > +    echo >>config SEABIOS_URL=\\"$r{tree_seabios}\\"
> > > +    echo >>config LIBVIRT_URL=\\"$r{tree_libvirt}\\"
> > > +    echo >>config OVMF_URL=\\"$r{tree_ovmf}\\"
> > 
> > What will raisin do if one or more of these runvars is not set for some
> > reason yet the thing is listed in ENABLED_COMPONENTS?
> 
> It will fail with an error and quit

Imagine a future version of this test script which has been extended to
support some new component, something which we cannot (or don't way to)
test with an older version of Xen (perhaps it doesn't build, or relies
on some newer Xen version somehow).

In that case we would want osstest to instruct raisin to not build that
component, which we would likely do by omitting the component from the
runvars I think.

So ENABLED_COMPONENTS needs to be generated too, not just hardcoded. I
suppose we could do it in an ad-hoc way every time we add a new
component to this base set, but that seems like it would get even uglier
than just doing it now.

The converse is also worth consideration -- what if osstest asks raisin
to build something it doesn't know about (imagine e.g. a bisection over
a raisin change to add a component).

> > > +    store_revision($ho, 'xen', "$raisindir/xen-dir", 1);
> > > +    store_revision($ho, 'qemu', "$raisindir/qemu-traditional-dir", 1);
> > > +    store_revision($ho, 'qemuu', "$raisindir/qemu-dir", 1);
> > > +    store_revision($ho, 'seabios', "$raisindir/seabios-dir", 1);
> > > +    store_revision($ho, 'ovmf', "$raisindir/ovmf-dir", 1);
> > > +    store_revision($ho, 'libvirt', "$raisindir/libvirt-dir", 1);
> > 
> > Is $component-dir considered a stable path in raisin (i.e. will you
> > promise not to change it).
> 
> This is a good point. If it is not stable now, it will have to be stable
> by the time this patch is accepted :-)

Right, I just wanted to give you the chance to change it now before we
rely on it ;-)

Ian.