qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] more automated/public CI for QEMU pullreqs


From: Paolo Bonzini
Subject: Re: [Qemu-devel] more automated/public CI for QEMU pullreqs
Date: Thu, 22 Aug 2019 19:05:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 22/08/19 18:50, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (address@hidden) wrote:
>> On 22/08/19 18:31, Dr. David Alan Gilbert wrote:
>>>> With both these points in mind, I think it is  pretty hard sell to
>>>> say we should write & maintain a custom CI system just for QEMU
>>>> unless it is offering major compelling functionality we can't do
>>>> without.
> 
> (That was Dan's comment)
> 
>> In theory I agree.
>>
>> In practice, the major compelling functionality is portability.  If it
>> is true that setting up runners is problematic even on aarch64, frankly
>> GitLab CI is dead on arrival.  If it is not true, then I'd be very happy
>> to use GitLab CI too.
> 
> IMHO if for some weird reason Gitlab has problems on aarch64 then we
> just need to get that fixed.

I'm sure it's just some packaging or deployment issue.  But
https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725 has been
open for more than one year; the last two messages are:

* 1 month ago: "I hope we will be able to merge it soon"

* 3 weeks ago: "Today I tried use gitlab-runner on my arm64 box, however
it kept mysteriously failing"

So the question is simply who does the work.

Paolo

> Dave
> 
>> Paolo
>>
>>> I'd agree; and I'd also find it useful to have runners setup for
>>> Gitlab CI for related things (it would be useful for the virtio-fs
>>> stuff);  if there are problems on other architectures then we should
>>> find some go wranglers to go fix it.
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK
> 




reply via email to

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