gitlab shared runner time expired

gitlab shared runner time expired

[Richard Henderson]

So, here we are again, out of runner time with 13 days left in the month.

Did we come to any resolution since last time?  Holding development for that long just 
isn't right, so I'll continue processing the hard way -- testing on private runners and 
local build machines.


r~

Re: gitlab shared runner time expired

[Eldon Stegall]

On Thu, May 18, 2023 at 12:26:33PM -0700, Richard Henderson wrote:
> So, here we are again, out of runner time with 13 days left in the month.
> 
> Did we come to any resolution since last time?  Holding development for that long just 
> isn't right, so I'll continue processing the hard way -- testing on private runners and 
> local build machines.

Hi Richard,
We should have capacity for private runners to execute several jobs in
parallel.  Here [1] is an example of one that ran on a private runner today.

I have been thinking about suggesting a strategy to run jobs that lend
themselves to amd64 linux runners pinned to private runners that match,
so more "shared" minutes can be spent on runners that have different
capabilites.

If there is another specific arch/OS runner you have in mind, I would be
happy to make efforts towards provisioning one in our infrastructure.
Particularly it seems like a lot of people are trying to use qemu to
support amd64 linux on M1 macs, so it might make sense to have a private
mac silicon macOS runner.

Also, since we have a hardware runner that can run with kvm capabilites,
it might make sense to carve some of those tests out for that tagged
runner. 

Since this is relatively new, I think I was personally in an observational
period before seeking input on those goals, but let me know you thoughts.

Thanks,
Eldon

[1] https://gitlab.com/qemu-project/qemu/-/jobs/4310866300

Re: gitlab shared runner time expired

[Mark Cave-Ayland]

On 18/05/2023 20:26, Richard Henderson wrote:

> So, here we are again, out of runner time with 13 days left in the month.
> 
> Did we come to any resolution since last time?  Holding development for that long 
> just isn't right, so I'll continue processing the hard way -- testing on private 
> runners and local build machines.

Since Daniel's latest gitlab series has proved that variable substitution can work 
with our gitlab template setup, I believe it should be possible to add some rules 
that can redirect pushes to the qemu-project "staging" branch for members of a 
"committers" group to the private runners (such as the ones set up by Eldon).


ATB,

Mark.

Re: gitlab shared runner time expired

[Paolo Bonzini]

On 5/18/23 21:26, Richard Henderson wrote:
> So, here we are again, out of runner time with 13 days left in the month.
> 
> Did we come to any resolution since last time?  Holding development for 
> that long just isn't right, so I'll continue processing the hard way -- 
> testing on private runners and local build machines.

Hi,

Camilla Conte has set up a Kubernetes-based runner on Azure.  If you
apply the two patches here:

    https://lore.kernel.org/qemu-devel/20230407145252.32955-1-cconte@redhat.com/

You should be able to run pipelines almost as usual, just with

    git push -o ci.variable=RUNNER_TAG=k8s ...

Camilla, please confirm that this is correct.

Paolo

Re: gitlab shared runner time expired

[Camilla Conte]

Hi!

On Fri, May 19, 2023 at 9:35 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
> You should be able to run pipelines almost as usual, just with
>
>     git push -o ci.variable=RUNNER_TAG=k8s ...
>
> Camilla, please confirm that this is correct.

Looks good.

Re: gitlab shared runner time expired

[Daniel P. Berrangé]

On Thu, May 18, 2023 at 12:26:33PM -0700, Richard Henderson wrote:
> So, here we are again, out of runner time with 13 days left in the month.
> 
> Did we come to any resolution since last time?  Holding development for that
> long just isn't right, so I'll continue processing the hard way -- testing
> on private runners and local build machines.

There's nothing we need todo, as the jobs are automatically landing on
Eldon's private runner AFAIK. We'll see the scary message about exhausting
all minutes on every job page, but aside from that, everything should
continue working as normal.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: gitlab shared runner time expired

[Peter Maydell]

On Thu, 18 May 2023 at 20:27, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> So, here we are again, out of runner time with 13 days left in the month.

This is quite early -- have you been processing pull requests
strictly one at a time, or in (small) batches ?

-- PMM

Re: gitlab shared runner time expired

[Richard Henderson]

On 5/19/23 02:18, Peter Maydell wrote:
> On Thu, 18 May 2023 at 20:27, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> So, here we are again, out of runner time with 13 days left in the month.
> 
> This is quite early -- have you been processing pull requests
> strictly one at a time, or in (small) batches ?

Mostly one at a time, because most pull requests have had errors.  Every single time I've 
tried to batch them this month it has been futile.


r~

Re: gitlab shared runner time expired

[Richard Henderson]

On 5/18/23 17:41, Eldon Stegall wrote:
> On Thu, May 18, 2023 at 12:26:33PM -0700, Richard Henderson wrote:
>> So, here we are again, out of runner time with 13 days left in the month.
>>
>> Did we come to any resolution since last time?  Holding development for that long just
>> isn't right, so I'll continue processing the hard way -- testing on private runners and
>> local build machines.
> 
> Hi Richard,
> We should have capacity for private runners to execute several jobs in
> parallel.  Here [1] is an example of one that ran on a private runner today.

That is excellent news, thank you.

> 
> I have been thinking about suggesting a strategy to run jobs that lend
> themselves to amd64 linux runners pinned to private runners that match,
> so more "shared" minutes can be spent on runners that have different
> capabilites.

Yes, I think that would be a good strategy.

> Particularly it seems like a lot of people are trying to use qemu to
> support amd64 linux on M1 macs, so it might make sense to have a private
> mac silicon macOS runner.

Yes, we get a fair few bug reports for macos.

> 
> Also, since we have a hardware runner that can run with kvm capabilites,
> it might make sense to carve some of those tests out for that tagged
> runner.
> 
> Since this is relatively new, I think I was personally in an observational
> period before seeking input on those goals, but let me know you thoughts.

Indeed.


r~