qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eldon Stegall <eldon-qemu@eldondev.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Kevin Wolf" <kwolf@redhat.com>, "John Snow" <jsnow@redhat.com>
Subject: Re: no more pullreq processing til February
Date: Fri, 27 Jan 2023 09:53:32 +0000	[thread overview]
Message-ID: <Y9OfHNRi+Wb3EEoO@redhat.com> (raw)
In-Reply-To: <Y9LJbvFf0N3BJBKq@invalid>

On Thu, Jan 26, 2023 at 06:41:50PM +0000, Eldon Stegall wrote:

> As far as baremetal goes, I find authenticated IPXE scripts work well
> for a number of these scenarios, and permit very dynamic allocation of
> resources. I have been a fan of the ignition/coreos/fcos strategy for
> baremetal deployment due to the capability to run the full system in
> memory, as writing packaging to disk can waste time and flash in my
> opinion. I strongly agree with the benefits of managing these components
> in the repo. Dockerfile, ignition config, or cloud-config would probably
> work.  Dockerfile makes sense to me if existing work in that direction
> has interest and docker is sufficiently flexible for the tests. That
> said, it may be easier to generate an appropriate cloud-config if no
> work is yet done on running tests inside docker.

One of the critical factors for QEMU CI is reproducability by
contributors. This is a critical reason why we want do CI
inside containers to the greatest extent possible. It lets
the maintainer eithuer pull down the same container build, or
rebuild the container image locally. This has given us a much
better ability to reproduce CI failures than we have before
we used containers so widely.

> I have looked through the .gitlab-cl.d directory in the repo, and it
> seems that there is existing work done with containers in the
> container-template.yml. Do we also incur minutes for our cirrus builds
> equivalent to the duration of the build on cirrus? Maybe relocation
> those builds would be the most effective? It seems that a number of
> builds unrelated to cirrus use containers already, or I am missing
> something?

We have a two phase CI pipeline. In the first phase we build all
the container images that we need. This uses cache, reusing layers
from containers in the previous build to reduce time spent. In
the second phase we run the actual QEMU build jobs inside the
containers we built in the first phase.

The cirrus jobs are special. We want gitlab to act as the single
frontend for all CI jobs. So we use a tool called cirrus-run in
the gitlab job to spawn a job on Cirrus CI and pull back the
results. This is only used for FreeBSD/macOS/Windows, which is
a pretty small part of our set of jobs.


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



  reply	other threads:[~2023-01-27  9:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 13:22 no more pullreq processing til February Peter Maydell
2023-01-26 13:52 ` Eldon Stegall
2023-01-26 14:13   ` Alex Bennée
2023-01-26 14:27     ` Peter Maydell
2023-01-26 14:38     ` Daniel P. Berrangé
2023-01-26 18:41       ` Eldon Stegall
2023-01-27  9:53         ` Daniel P. Berrangé [this message]
2023-01-26 14:18   ` Daniel P. Berrangé
2023-01-26 14:30     ` Daniel P. Berrangé
2023-01-27  8:50       ` Gerd Hoffmann
2023-01-26 13:57 ` Alex Bennée
2023-01-26 14:07   ` Daniel Henrique Barboza
2023-01-26 14:27     ` Daniel P. Berrangé
2023-01-26 14:35   ` Daniel P. Berrangé
2023-01-26 14:41     ` Peter Maydell
2023-01-26 18:17       ` Thomas Huth
2023-01-26 20:49         ` Alex Bennée
2023-01-26 14:25 ` Stefan Hajnoczi
2023-01-26 14:28   ` Peter Maydell
2023-01-27  7:36     ` Thomas Huth
2023-01-27 12:39     ` Kevin Wolf
2023-01-27 12:47       ` Daniel P. Berrangé
2023-01-27 13:11       ` Peter Maydell
2023-01-27 13:12         ` Peter Maydell
2023-02-01 16:18       ` Peter Maydell
2023-01-27  9:30 ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y9OfHNRi+Wb3EEoO@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=eldon-qemu@eldondev.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).