qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alex Bennée
Subject: Re: [Qemu-devel] State of QEMU CI as we enter 4.0
Date: Fri, 15 Mar 2019 17:54:03 +0000
User-agent: mu4e 1.1.0; emacs 26.1

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



reply via email to

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