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.mayd...@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 :|
