Re: no more pullreq processing til February

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

On Thu, Jan 26, 2023 at 11:07:37AM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 1/26/23 10:57, Alex Bennée wrote:
> > 
> > Peter Maydell <peter.maydell@linaro.org> writes:
> > 
> > > 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 :-)
> > 
> > I've submitted a support request (#366644) to GitLab to see if they will
> > give us more minutes for this month. Longer term ideas:
> > 
> >   * Reduce compile time by reducing number of identical object files we
> >     build for specific_ss
> >   * Move more tests over to custom runners (don't we have an x86 box
> >     somewhere?)
> >   * Carry out an audit of code coverage for different test sets and
> >     rationalise our CI set
> 
> What about sub-maintainers running the CI jobs before sending PRs? Should we
> stop it? I usually do a full CI run before sending a ppc queue but if we're
> having problems with gitlab pipeline minutes then perhaps we should stop
> doing that.

Any CI you run in your repo fork has no impact on QEMU CI allowance
upstream.

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