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

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(-)

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'

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

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