| Message ID | 20220824094029.1634519-51-bmeng.cn@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | tests/qtest: Enable running qtest on Windows | expand |
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
On Thu, Aug 25, 2022 at 4:18 PM Thomas Huth <thuth@redhat.com> 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 90 minutes is okay for "make -j2" on the CI machine, but if we disable the parallel build I am afraid 90 minutes is not enough. > 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 ?) I believe the build takes more time than the testing. But definitely the latest migration test speed up patch will help on windows too. Regards, Bin
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
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 before_script: - If ( !(Test-Path -Path msys64\var\cache ) ) { mkdir msys64\var\cache @@ -59,7 +59,7 @@ msys2-64bit: - $env:MSYSTEM = 'MINGW64' # Start a 64 bit Mingw environment - $env:MSYS = 'winsymlinks:native' # Enable native Windows symlink - .\msys64\usr\bin\bash -lc './configure --target-list=x86_64-softmmu - --enable-capstone --without-default-devices' + --enable-capstone' - .\msys64\usr\bin\bash -lc "sed -i '/^ROMS=/d' build/config-host.mak" - .\msys64\usr\bin\bash -lc 'make -j2' - .\msys64\usr\bin\bash -lc 'make check'