[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.
>