Re: no more pullreq processing til February

[Alex Bennée]

Eldon Stegall <eldon-qemu@eldondev.com> writes:

> On Thu, Jan 26, 2023 at 01:22:32PM +0000, Peter Maydell wrote:
>> Hi; we've run out of gitlab CI pipeline minutes for this month.
>> This leaves us the choice of:
>>  (a) don't process any more pullreqs til we get more minutes in Feb
>>  (b) merge pullreqs blindly without CI testing
>>  (c) buy more minutes
>> 
>> For the moment I propose to take option (a). My mail filter will
>> continue to track pullreqs that get sent to the list, but I won't
>> do anything with them.
>> 
>> If anybody has a better suggestion feel free :-)
>
> Would it be possible if (d) were to run self-hosted instances of the
> runner? I am not sure how gitlab pricing works, but I believe on github
> self-hosted runners are free.

Yes running more stuff on custom runners would be great (and also
possibly not as slow as the heavily loaded shared runners).

> I have several baremetal machines colocated that I could dedicate to
> execute these runs, dual processor xeons with a couple hundred gigs of
> RAM. I would need approx 48 hours notice to initially provision the
> machines. I would be happy to provide root credentials and work out IPMI
> access if that becomes necessary.

I think we would need:

  - provisioning scripts in scripts/ci/setup (if existing not already
    good enough)
  - tweak to handle multiple runner instances (or more -j on the build)
  - changes to .gitlab-ci.d/ so we can use those machines while keeping
    ability to run on shared runners for those outside the project

> If this offering isn't suitable, let me know how we can consider
> adapting something to the project's needs.
>
> Thanks,
> Eldon


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro