On Sat, Sep 24, 2022 at 12:24 AM Alex Bennée <alex.ben...@linaro.org> wrote:
>
>
> Bin Meng <bmeng...@gmail.com> writes:
>
> > 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 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
