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@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'
+
+
+.qemu-build-template: &qemu-build-template
+ - git clone --depth 1 https://gitlab.com/qemu-project/qemu.git
+ - cd qemu
+ #
+ # QEMU's .native_build_job_template bits
+ - export TARGETS="x86_64-softmmu"
+ - export CONFIGURE_ARGS="--prefix=/usr"
+ - export MAKE_CHECK_ARGS="check-build"
+ - !reference [.native_build_job_template, before_script]
+ - !reference [.native_build_job_template, script]
+ - sudo make install
.install-deps: &install-deps
--
2.34.1On 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@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. > +.qemu-build-template: &qemu-build-template > + - git clone --depth 1 https://gitlab.com/qemu-project/qemu.git > + - cd qemu > + # > + # QEMU's .native_build_job_template bits > + - export TARGETS="x86_64-softmmu" > + - export CONFIGURE_ARGS="--prefix=/usr" > + - export MAKE_CHECK_ARGS="check-build" > + - !reference [.native_build_job_template, before_script] > + - !reference [.native_build_job_template, script] > + - sudo make install > > > .install-deps: &install-deps > -- > 2.34.1 > 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 :|
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@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. 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. Erik > > > +.qemu-build-template: &qemu-build-template > > + - git clone --depth 1 https://gitlab.com/qemu-project/qemu.git > > + - cd qemu > > + # > > + # QEMU's .native_build_job_template bits > > + - export TARGETS="x86_64-softmmu" > > + - export CONFIGURE_ARGS="--prefix=/usr" > > + - export MAKE_CHECK_ARGS="check-build" > > + - !reference [.native_build_job_template, before_script] > > + - !reference [.native_build_job_template, script] > > + - sudo make install > > > > > > .install-deps: &install-deps > > -- > > 2.34.1 > > > > 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 :| >
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@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 :|
On Wed, May 11, 2022 at 03:07:43PM +0100, Daniel P. Berrangé wrote: > 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@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. Are you sure they are pushed ? There's no job appearing: https://gitlab.com/libvirt/libvirt/-/pipelines/536112780 and I'm not seeing them after fetching latest origin/master 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 :|
On Wed, May 11, 2022 at 03:11:01PM +0100, Daniel P. Berrangé wrote: > On Wed, May 11, 2022 at 03:07:43PM +0100, Daniel P. Berrangé wrote: > > 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@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. > > Are you sure they are pushed ? There's no job appearing: > > https://gitlab.com/libvirt/libvirt/-/pipelines/536112780 > > and I'm not seeing them after fetching latest origin/master Doh! Indeed they are not. I remember merging them to my local master and then a meeting distracted me from pushing them and then I clearly forgot to do it, but my head convinced me that I had done it :). Alright then, let me copy-paste the QEMU build job template to libvirt instead of pulling it. Erik
© 2016 - 2026 Red Hat, Inc.