qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v5 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI)


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v5 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI)
Date: Fri, 5 Mar 2021 11:27:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 3/5/21 11:14 AM, Philippe Mathieu-Daudé wrote:
> Hi Cleber,
> 
> On 2/19/21 10:58 PM, Cleber Rosa wrote:
>> TL;DR: this should allow the QEMU maintainer to push to the staging
>> branch, and have custom jobs running on the project's aarch64 and
>> s390x machines.  Jobs in this version are allowed to fail, to allow
>> for the inclusion of the novel machines/jobs without CI disruption.
>> Simple usage looks like:
>>
>>    git push remote staging
>>    ./scripts/ci/gitlab-pipeline-status --verbose --wait
>>
>> Long version:
>>
>> The idea about a public facing Gating CI for QEMU was summarized in an
>> RFC[1].  Since then, it was decided that a simpler version should be
>> attempted first.
>>
>> At this point, there are two specific runners (an aarch64 and an s390x)
>> registered with GitLab, at https://gitlab.com/qemu-project, currently
>> setup to the "qemu" repository.

Also we are interested in testing virtualization with these runners.

If KVM is available, we need to document the gitlab-runner user needs
to be in the KVM group, and it would be helpful to have a 'kvm' tag
in the runner taglist, so we could assign specific jobs to these
runners.

> Our CI is heavily based on containerized testing, your scripts/document
> don't cover that.
> 
> Should we document how to install a container service (we mostly
> use Docker and Podman)?
> 
> Or should we simply explicit these are only "native" runners and
> container support will be considered later eventually?
> 
> Regards,
> 
> Phil.
> 




reply via email to

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