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