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

[Thomas Huth]

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...
(maybe the tests now also work a little bit faster now that the migration 
test has been speed up in 7.1-rc4 ?)

 Thomas