On 16/12/2022 17.23, Philippe Mathieu-Daudé wrote:
On 16/12/22 15:55, Peter Maydell wrote:
The msys2-32bit job currently seems to run into the 70 minute CI timeout
quite frequently. This successful pass took 61 minutes:
https://gitlab.com/qemu-project/qemu/-/jobs/3479763757
so I don't think it's a "time limit is fine but job has intermittent
hang" situation.
msys2-64bit also is quite close to the timeout, eg this job
https://gitlab.com/qemu-project/qemu/-/jobs/3482192864
took 61 minutes.
The 64-bit variant is building WHPX.
Can we cut down or split up these CI jobs?
The Windows jobs are terribly slow, yes, and we've discussed that a couple
of times before with no satisfying solution, e.g.:
https://lore.kernel.org/qemu-devel/e80726cc-633d-435c-7a2a-5cae43624...@redhat.com/
... so we currently settled on not running the qtests in the 64-bit job
since that would take too long.
I also don't have a real good idea how to improve the situation ... we could
switch to even simpler targets (e.g. s390x-softmmu should compile faster and
run less tests than ppc64-softmmu, I think), or would it be still OK to bump
the timeout to 80 minutes here? (90 minutes, like it has been discussed last
year is already very borderline, but I think 80 minutes might still be OK,
especially since those jobs don't wait for another job from the container
stage?)
We can add --disable-tools to the slower.
For the 32-bit job, this would further decrease the test scope ... should be
OK as a last resort, I guess.
What I don't understand is why the docker image is rebuilt, it should
be pulled from the registry.
I think those Windows jobs are still quite a bit special ... e.g. until some
months ago, the "timeout" setting was also not working at all IIRC.
Thomas
