Re: no more pullreq processing til February

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jan 26, 2023 at 02:18:23PM +0000, Daniel P. Berrangé wrote:
> On Thu, Jan 26, 2023 at 01:52:39PM +0000, Eldon Stegall wrote:
> > 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.
> > 
> > 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.
> 
> We do currently have some private runners registered against the
> /qemu-project namespace, so we can do some non-x86 native testing.
> 
> The challenge is the integration and configuration. The GitLab CI
> YAML config rules need to be written such that specific jobs  get
> targetted for the right private runners, instead of the shared
> runners, by including the 'tags' element in the job config, and
> some 'rules' logic.

Scratch that, it is actually possible to configure private runners
to pick up un-tagged jobs

https://docs.gitlab.com/ee/ci/runners/configure_runners.html#runner-is-allowed-to-run-untagged-jobs

i'm not sure what the prioritization  is between shared and private
runners when using untagged jobs though. If a share runners will
pick up untagged jobs and then error them due to lack of CI credits
that might prevent our private runner picking up the untagged jobs.
We could turn off shared runners entirely potentially.

We would need the private runner to be configured with the docker
engine, so it can handle our container based approach.

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 :|