On 8/22/19 7:05 PM, Paolo Bonzini wrote: > On 22/08/19 18:50, Dr. David Alan Gilbert wrote: >> * Paolo Bonzini (pbonz...@redhat.com) wrote: >>> On 22/08/19 18:31, Dr. David Alan Gilbert wrote: >>>>> With both these points in mind, I think it is pretty hard sell to >>>>> say we should write & maintain a custom CI system just for QEMU >>>>> unless it is offering major compelling functionality we can't do >>>>> without. >> >> (That was Dan's comment) >> >>> In theory I agree. >>> >>> In practice, the major compelling functionality is portability. If it >>> is true that setting up runners is problematic even on aarch64, frankly >>> GitLab CI is dead on arrival. If it is not true, then I'd be very happy >>> to use GitLab CI too. >> >> IMHO if for some weird reason Gitlab has problems on aarch64 then we >> just need to get that fixed. > > I'm sure it's just some packaging or deployment issue. But > https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725 has been > open for more than one year; the last two messages are: > > * 1 month ago: "I hope we will be able to merge it soon" > > * 3 weeks ago: "Today I tried use gitlab-runner on my arm64 box, however > it kept mysteriously failing" > > So the question is simply who does the work.
IIRC Samuel Ortiz told he was using GitLab with Aarch64 runners around Nov 2018, but "compiling from source". Alex Bennée tried building it on our Packet server during early 2019. Later an (unattended?) Ubuntu upgrade installed a package that does not work anymore with current GitLab server. I noticed this few months ago, built it again and tested it, then looked at what was wrong with the upstream MR. The Aarch64 packaging succeed when cross-building on x86_64 host, but fails when building natively... Since part of it is "built or tested in the cloud" and involving Go, I simply let a comment: https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725#note_183470145 So to confirm what Paolo said, GitLab runners work on Aarch64 (and we have it well tested), however there is a packaging issue, so it does not work "out of the box". Related to: Runner compiled with Go 1.8.7 seems to not work properly with multiarch support. Executing the binary built with Go 1.8.7 results with an error [...] There has been 1 recent fix for the go runner: https://bugs.launchpad.net/qemu/+bug/1838946/comments/1 And there is an ongoing discussion about "patch to swap SIGRTMIN + 1 and SIGRTMAX - 1".
