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 <f...@euphon.net> wrote: > > > > On Mar 15, 2019, at 17:58, Alex Bennée <alex.ben...@linaro.org> wrote: > > > > > > Fam Zheng <f...@euphon.net> writes: > > > >>> On Mar 15, 2019, at 16:57, Alex Bennée <alex.ben...@linaro.org> 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 >
