qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3] travis-ci: Disable C++ optional objects on AArch64 contai


From: Thomas Huth
Subject: Re: [PATCH v3] travis-ci: Disable C++ optional objects on AArch64 container
Date: Tue, 9 Feb 2021 15:16:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 09/02/2021 15.12, Philippe Mathieu-Daudé wrote:
On 2/9/21 2:41 PM, Peter Maydell wrote:
On Tue, 9 Feb 2021 at 13:32, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
Migration of this job is pending of Cleber's possibility to add an AArch64
runner to Gitlab-CI, right? Then we need someone to support and maintain
the hardware... I don't think anybody volunteered.

We have the hardware already. Effectively Alex is maintaining it...

I missed to read if Alex volunteered for this task but am certainly
happy if he is :) Although this should be documented somewhere (who
to contact if the AArch64 runner starts to fail?).

Assuming Cleber's runner script is merged and working on the AArch64
runner, then we need to figure how contributors can use it.
Assuming this runner will be registered under the QEMU organization
namespace in Gitlab, then contributors would have to open a Merge
Request to trigger the CI jobs (similarly to when you push to the
/staging branch). Then we would cancel the MR. We can ask contributors
to cancel their MR once testing done.

I'm not sure, but if I got that right, opening a MR will only trigger a CI run on side of the requester, not of the target project? For example, when I look at:

 https://gitlab.com/libvirt/libvirt/-/merge_requests/65

the pipeline that is shown there ran on side of the requester, not on side of the libvirt project?

 Thomas




reply via email to

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