Message ID | 20210219215838.752547-1-crosa@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | GitLab Custom Runners and Jobs (was: QEMU Gating CI) | expand |
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. 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.
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. >
Cleber Rosa <crosa@redhat.com> writes: > 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. > > Changes from v4: Was there a v6 I missed?