On Mon, Mar 03, 2025 at 07:01:16PM +0800, Stefan Hajnoczi wrote: > On Mon, Mar 3, 2025 at 5:26 PM Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > On Mon, Mar 3, 2025 at 8:35 AM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > GitLab says: > > > "There has been a timeout failure or the job got stuck. Check your > > > timeout limits or try again" > > > > > > Duration: 77 minutes 13 seconds > > > Timeout: 1h (from project) > > > > > > It ran 17 minutes longer than the job timeout. > > > > The job only seems to have run for roughly 15-20 minutes. > > > > I am not sure what's going on, but I have opened a ticket with DO to > > request both larger droplets (16 vCPU / 32 GB) and a higher limit (25 > > droplets). This matches roughly what was available on Azure. > > > > Let me know if you prefer to go back to Azure for the time being. > > Yes, please. I'm unable to merge pull requests (with a clear > conscience at least) because running CI to completion is taking so > long with many manual retries needed. > > Perhaps the timeouts will go away once the droplet size is increased. > It makes sense that running the jobs on different hardware might > require readjusting timeouts.
It is a bit surprising to see timeouts, as we've fine tuned our test timeouts to cope with GitLab's default shared runners, which is what contributors use when CI runs in a fork. These runners only have 2 VCPUs and 8 GB of RAM, so that's a pretty low resource baseline 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 :|
