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