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: Ed Vielmetti
Subject: Re: [Qemu-devel] State of QEMU CI as we enter 4.0
Date: Fri, 15 Mar 2019 11:02:13 -0400

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

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.

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
>


reply via email to

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