qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: no more pullreq processing til February


From: Eldon Stegall
Subject: Re: no more pullreq processing til February
Date: Thu, 26 Jan 2023 18:41:50 +0000

On Thu, Jan 26, 2023 at 02:38:23PM +0000, Daniel P. Berrangé wrote:
> The current approach for provisioning our private runners is highly
> undesirable IMHO. We are installing the full set of build deps on
> the host OS install, at time of provisioning the runner.
> 
> We should instead be provisioning the hosts exclusively to have
> docker, and then use containers for the build + test environment,
> so we don't need to have sysadmin intervention on the runners when
> a merge request adds a build dep.
> 
> If we want to new private runners to replace the shared runners
> transparently, then the use of docker is basically a must have.

This is how I currently do yocto builds for my current primary concern,
provision the machines, and the docker-compose run the tests and builds.

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.

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?

I will try to familiarize myself further with this directory. I will try
adding some runners to my fork and seeing what the tests look like
there.

Thanks,
Eldon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]