Re: [PATCH 50/51] .gitlab-ci.d/windows.yml: Increase the timeout to the runner limit

[Daniel P . Berrangé]

On Thu, Aug 25, 2022 at 10:18:06AM +0200, Thomas Huth wrote:
> On 24/08/2022 11.40, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> > 
> > commit 9f8e6cad65a6 ("gitlab-ci: Speed up the msys2-64bit job by using 
> > --without-default-devices"
> > changed to compile QEMU with the --without-default-devices switch for
> > the msys2-64bit job, due to the build could not complete within the
> > project timeout (1h), and also mentioned that a bigger timeout was
> > getting ignored on the shared Gitlab-CI Windows runners.
> > 
> > However as of today it seems the shared Gitlab-CI Windows runners does
> > honor the job timeout, and the runner has the timeout limit of 2h, so
> > let's increase the timeout to the runner limit and drop the configure
> > switch "--without-default-devices" to get a larger build coverage.
> > 
> > As a result of this, the check-qtest starts running on Windows in CI.
> > 
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> > 
> >   .gitlab-ci.d/windows.yml | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/.gitlab-ci.d/windows.yml b/.gitlab-ci.d/windows.yml
> > index c4bde758be..d4fd821b5f 100644
> > --- a/.gitlab-ci.d/windows.yml
> > +++ b/.gitlab-ci.d/windows.yml
> > @@ -10,7 +10,7 @@
> >         - ${CI_PROJECT_DIR}/msys64/var/cache
> >     needs: []
> >     stage: build
> > -  timeout: 70m
> > +  timeout: 2h
> 
> IMHO 2 hours are too long ... we're normally trying to limit the time of
> each job to 1h only and only extend it a little bit if we cannot really
> make, but we should not double the amount of time here. The highest timeout
> that we currently have are 90 minutes ... would that still be OK for this
> job, too? If so, please use 90 minutes here. Otherwise, it might still be
> necessary to cut down this job here and there a little bit...

Also note that 90 minutes is not considered the typical execution
time. For a 90 minute timeout, we should expect the job to run
much quicker than that under normal CI load. eg a 90 minute timeout
should imply a job typically runs in 60-70 minutes, leaving some slack.

IMHO if normal execution of a job takes >60 minutes, we need to
turn off features in CI to get it faster, or split it across
multiple jobs, not increase the timeout even more.


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