On 24/08/2022 11.40, Bin Meng wrote:
From: Bin Meng <bin.m...@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.m...@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
