[libvirt PATCH 3/5] ci: Introduce a template for upstream QEMU build

[Daniel P. Berrangé]

On Wed, May 11, 2022 at 04:04:54PM +0200, Erik Skultety wrote:
> On Wed, May 11, 2022 at 03:01:51PM +0100, Daniel P. Berrangé wrote:
> > On Fri, May 06, 2022 at 05:35:18PM +0200, Erik Skultety wrote:
> > > Rather than writing down the steps to build QEMU from source ourselves
> > > let's recycle what upstream QEMU uses in their CI. This has the obvious
> > > advantage that if QEMU changes something in their upstream CI build
> > > process we'll pull the change automatically.
> > > Since YAML anchors cannot be used in a cross-file scenario this patch
> > > makes use of the '!reference' keyword which allows us go even further
> > > and thus pick useful parts from the upstream QEMU's CI build template.
> > > In addition, we're also able to add more intermediary steps to these
> > > hand-picked QEMU build job sections.
> > > 
> > > Signed-off-by: Erik Skultety <eskultet at redhat.com>
> > > ---
> > >  ci/integration-template.yml | 17 +++++++++++++++++
> > >  1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/ci/integration-template.yml b/ci/integration-template.yml
> > > index 195e9cfa5f..d1934b1469 100644
> > > --- a/ci/integration-template.yml
> > > +++ b/ci/integration-template.yml
> > > @@ -1,3 +1,20 @@
> > > +# We want to reuse QEMU's .native_build_job_template to build it from source
> > > +include:
> > > +  - project: 'qemu-project/qemu'
> > > +    file: '.gitlab-ci.d/buildtest-template.yml'
> > 
> > I don't think doing this is a good idea, because it is essentially a
> > private impl detail of QEMU's current CI setup that can be changed
> > at any time.
> > 
> > Doing a simple QEMU build isn't complex, so I think we're fine to
> > just put the logic in our code here directly.
> 
> Well, sorry I already pushed the patches a day after mprivozn ACKed them.

Oh, I didn't see them in my local tree, so thought they weren't pushed
yet.

> Besides, why is it bad that QEMU changes their build? Isn't it actually
> beneficial for us to build QEMU the exact same way as they do for integration
> purposes? I think that it alleviates any maintenance burden off our shoulders.

I was refering to more to the existance of a 'buildtest-template.yml'
file, or to the existance of specific build job names in this file,
all of which have changed multiple times in QEMU.

Conversely the actual way to invoke a QEMU build has not changed
in the same timeframe.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|