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

[Ed Vielmetti]

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.

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
>