qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 00/11] Optional gitlab-CI and doc fixes for -rc4


From: Alexander Bulekov
Subject: Re: [PULL 00/11] Optional gitlab-CI and doc fixes for -rc4
Date: Mon, 16 Aug 2021 08:00:35 -0400

On 210816 1340, Philippe Mathieu-Daudé wrote:
> On 8/16/21 1:30 PM, Alexander Bulekov wrote:
> > On 210816 1211, Daniel P. Berrangé wrote:
> >> On Mon, Aug 16, 2021 at 06:22:46AM -0400, Alexander Bulekov wrote:
> 
> >>> https://gitlab.com/qemu-project/qemu/-/jobs/1505950978
> >>> Looks like build-oss-fuzz is still timing out, even without the issue
> >>> in the vhost-usr-blk test. At this point the job should essentially just
> >>> build + test qemu-system-i386 with some extra time spent on linking
> >>> the fuzzer and briefly running through all the fuzzer configs. Maybe the
> >>> only way to make this work is to split the job into a build + test
> >>> stage?
> >>
> >> At this point I think we should just disable the job in gitlab entirely.
> >> We've spent too long debugging this, while leaving CI red for everyone.
> >>
> >> Whomever is interested in this can then work to find a way to make it
> >> reliable and request it be re-enabled once confident that it will work.
> >>
> > 
> > On my mirror the job succeeded in 41 minutes... I guess you have to get
> > lucky with scheduling/ambient load.
> > https://gitlab.com/a1xndr/qemu/-/jobs/1506197531
> 
> TBH I stopped looking at this job console out because it fails too often
> in my pipelines :(
> 

Of course if the job times out 50% of the time, nobody will want to look
at it. And as a result, issues like the one with the vhost-user-blk
test are unnoticed. My hope was that removing the redundant build would
take care of timeouts. Maybe if we find that this new sporadic
timeout issue is also due to some test-failure, the job will again be
useful for someone.
-Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]