diff mbox series

[v2,36/39] .gitlab-ci.d/windows.yml: Increase the timeout to 90 minutes

Message ID 20220920103159.1865256-37-bmeng.cn@gmail.com (mailing list archive)
State New, archived
Headers show
Series tests/qtest: Enable running qtest on Windows | expand

Commit Message

Bin Meng Sept. 20, 2022, 10:31 a.m. UTC
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 90 minutes and drop the configure switch
"--without-default-devices" to get a larger build coverage.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
---

Changes in v2:
- Change the timeout limit to 90 minutes

 .gitlab-ci.d/windows.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Alex Bennée Sept. 23, 2022, 4:22 p.m. UTC | #1
Bin Meng <bmeng.cn@gmail.com> writes:

> 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 90 minutes and drop the configure switch
> "--without-default-devices" to get a larger build coverage.

I'd like to push back lightly against increasing the time because it
lengthens the total run time before we can merge a branch. Ideally we
could come up with a combination of build and tests that exercises all
the Windows code without exhaustively testing code paths that are tested
elsewhere. For device emulation are there any host specific things we
are testing?


>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> Changes in v2:
> - Change the timeout limit to 90 minutes
>
>  .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 da6013904a..818676662a 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: 90m
>    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'
>    - .\msys64\usr\bin\bash -lc 'make check'
Thomas Huth Sept. 23, 2022, 5:50 p.m. UTC | #2
On 23/09/2022 18.22, Alex Bennée wrote:
> 
> Bin Meng <bmeng.cn@gmail.com> writes:
> 
>> 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 90 minutes and drop the configure switch
>> "--without-default-devices" to get a larger build coverage.
> 
> I'd like to push back lightly against increasing the time because it
> lengthens the total run time before we can merge a branch. Ideally we
> could come up with a combination of build and tests that exercises all
> the Windows code without exhaustively testing code paths that are tested
> elsewhere. For device emulation are there any host specific things we
> are testing?

The problem is rather: With "--without-default-devices", make check is not 
working anymore since a lot of qtests expect certain devices to be around...

  Thomas
Bin Meng Sept. 24, 2022, 1:13 a.m. UTC | #3
On Sat, Sep 24, 2022 at 12:24 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Bin Meng <bmeng.cn@gmail.com> writes:
>
> > 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 90 minutes and drop the configure switch
> > "--without-default-devices" to get a larger build coverage.
>
> I'd like to push back lightly against increasing the time because it
> lengthens the total run time before we can merge a branch. Ideally we
> could come up with a combination of build and tests that exercises all
> the Windows code without exhaustively testing code paths that are tested
> elsewhere. For device emulation are there any host specific things we
> are testing?
>

Yes, the upcoming virtio-9p Windows support will update the qtests to
test the Windows specific 9p implementation.

Besides that, during the development of this patch series, several
QEMU code bugs were exposed only when we run qtests on Windows, or
even Windows 32-bit. I still see benefits of running qtests on
Windows.

The thing is that we need to find a more powerful machine to do the
CI. Current GitLab shared Windows runners are just too slow.

Regards,
Bin
diff mbox series

Patch

diff --git a/.gitlab-ci.d/windows.yml b/.gitlab-ci.d/windows.yml
index da6013904a..818676662a 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: 90m
   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'
   - .\msys64\usr\bin\bash -lc 'make check'