Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Alex Bennée]

Ed Vielmetti <address@hidden> writes:

> There are a couple of options hosted at Packet - Shippable, Codefresh, and
> Drone. I perhaps know more about Drone than the others. Each of them have a
> supported/sponsored version which can be used to produce arm64 binaries
> natively.
>
> I'll admit to dropping into this conversation in mid-stream though - what
> is the overall goal of this effort? Knowing that it might be easier to
> suggest a specific path.

Apologies I did drop you into the CC half-way. The thread can be viewed
in our archives:

  https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04909.html

but essentially as we finish another dev cycle we are reviewing our
current CI setup and looking to see how we can add additional
architectures to our current setup which is currently very x86 focused.

Individual developers have access to range of machines and the gitlab
runner approach looks quite promising. However it's proving to be harder
to setup in practice!

>
> On Fri, Mar 15, 2019 at 1:54 PM Alex Bennée <address@hidden> wrote:
>
>>
>> Ed Vielmetti <address@hidden> writes:
>>
>> > We have been trying to merge the Gitlab runner patches for arm64
>> > for over a year now; see
>> >
>> > https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725
>>
>> Yes I found that one. I'm trying to work out exactly how there build
>> system works. It seems to build all architectures on the same host using
>> QEMU to do so. I suspect this has never actually been run on a non-x86
>> host so I'm seeing if there is anything I can fix.
>>
>> I've already hit a bug with Debian's QEMU packaging which assumes that
>> an AArch64 box always supports AArch32 which isn't true on the TX
>> machines:
>>
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924667
>>
>> > I have not yet sorted out who at Gitlab has the ability to get
>> > this change implemented - their management structure is
>> > not something that I have sorted out yet, and I can't tell whether
>> > this lack of forward progress is something best to tackle by
>> > technical merit or by appealing to management.
>>
>> What about Shippable? I saw the press release you guys did but it is not
>> entirely clear if I need a paid licensed Bring You Own Node or if is there
>> a
>> free option for FLOSS projects?
>>
>> >
>> > On Fri, Mar 15, 2019 at 6:24 AM Fam Zheng <address@hidden> wrote:
>> >
>> >>
>> >>
>> >> > On Mar 15, 2019, at 17:58, Alex Bennée <address@hidden>
>> wrote:
>> >> >
>> >> >
>> >> > Fam Zheng <address@hidden> writes:
>> >> >
>> >> >>> On Mar 15, 2019, at 16:57, Alex Bennée <address@hidden>
>> wrote:
>> >> >>>
>> >> >>> I had installed the gitlab-runner from the Debian repo but it was
>> out
>> >> >>> of date and didn't seem to work correctly.
>> >> >>
>> >> >> If there can be a sidecar x86 box next to the test bot, it can be the
>> >> >> controller node which runs gitlab-runner, the test script (in
>> >> >> .gitlab-ci.yml) can then sshs into the actual env to run test
>> >> >> commands.
>> >> >
>> >> > Sure although that just adds complexity compared to spinning up a box
>> in
>> >> > the cloud ;-)
>> >>
>> >> In the middle is one controller node and a number of hetergeneous boxes
>> it
>> >> knows how to control with ssh.
>> >>
>> >> (BTW patchew tester only relies on vanilla python3 to work, though
>> clearly
>> >> it suffers from insufficient manpower assumed the SLA we'll need on the
>> >> merge test. It’s unfortunate that gitlab-runner is a binary.)
>> >>
>> >> Fam
>> >>
>>
>>
>> --
>> Alex Bennée
>>


--
Alex Bennée