[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/5] QEMU Gating CI
From: |
Cleber Rosa |
Subject: |
Re: [PATCH 0/5] QEMU Gating CI |
Date: |
Mon, 27 Apr 2020 10:28:35 -0400 |
On Mon, 27 Apr 2020 12:51:36 +0200
Philippe Mathieu-Daudé <address@hidden> wrote:
> On 4/27/20 7:12 AM, Cleber Rosa wrote:
> > On Thu, 23 Apr 2020 23:28:21 +0200
> > Philippe Mathieu-Daudé <address@hidden> wrote:
> [...]
> >> In some cases custom runners are acceptable. These runners won't be
> >> "gating" but can post informative log and status.
> >>
> >
> > Well, I have the feeling that some people maintaining those runners
> > will *not* want to have them as "informational" only. If they
> > invest a good amount of time on them, I believe they'll want to
> > reap the benefits such as other not breaking the code they rely on.
> > If their system is not gating, they lose that and may find
> > breakage that CI did not catch. Again, I don't think "easily
> > accessible" hardware should be the only criteria for
> > gating/non-gating status.
> >
> > For instance, would you consider, say, a "Raspberry Pi 4 Model
> > B", running KVM jobs to be a reproducible runner? Would you blame a
> > developer that breaks a Gating CI job on such a platform and says
> > that he can not reproduce it?
>
> I'm not sure I understood the problem, as I'd answer "yes" but I
> guess you expect me to say "no"?
>
What I mean is: would you blame such a developer for *not* having a
machine himself/herself that he/she can try to reproduce the failure?
And would you consider a "Raspberry Pi 4 Model B" an easily available
hardware?
> [...]
> >> Now the problem is GitLab runner is not natively available on the
> >> architectures listed in this mail, so custom setup is required. A
> >> dumb script running ssh to a machine also works (tested) but lot of
> >> manual tuning/maintenance expected.
> >>
> >
> > That's where I'm trying to help. I built and tested the
> > gitlab-runner for a number of non-supported environments, and I
> > expect to build further on that (say contributing code or feedback
> > back to GitLab so they become official builds?).
>
> Good luck with that, it took more that 2 years to GitLab to
> officially support AMD64:
> https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/725
>
You mean aarch64, sure. I'm not holding my breath, because we can
always have our own binaries/ports (or other executors such as ssh) but
I'm optimistic...
> Hopefully the first non-x86 user was the hardest one who had to do
> all the bad work, and next architecture might get supported quicker...
>
... and this point is one of the reasons. The other is competition
from Travis-CI (and others).
Cheers,
- Cleber.
- Re: [PATCH 0/5] QEMU Gating CI, (continued)
- Re: [PATCH 0/5] QEMU Gating CI, Philippe Mathieu-Daudé, 2020/04/23
- Re: [PATCH 0/5] QEMU Gating CI, Erik Skultety, 2020/04/24
- Re: [PATCH 0/5] QEMU Gating CI, Cleber Rosa, 2020/04/27
- Re: [PATCH 0/5] QEMU Gating CI, Andrea Bolognani, 2020/04/27
- Re: [PATCH 0/5] QEMU Gating CI, Cleber Rosa, 2020/04/27
- Re: [PATCH 0/5] QEMU Gating CI, Philippe Mathieu-Daudé, 2020/04/27
- Re: [PATCH 0/5] QEMU Gating CI,
Cleber Rosa <=
- Re: [PATCH 0/5] QEMU Gating CI, Philippe Mathieu-Daudé, 2020/04/27
- Re: [PATCH 0/5] QEMU Gating CI, Cleber Rosa, 2020/04/27
- Re: [PATCH 0/5] QEMU Gating CI, Daniel P . Berrangé, 2020/04/27