[edk2-devel] spurious CI failures

Michael D Kinney michael.d.kinney at intel.com
Wed Dec 22 22:45:11 UTC 2021


I agree that building QEMU from sources is another option.

We could also consider adding QEMU to the nuget feed we use for other tools, so we avoid the current server’s perf issues.

Mike

From: Pedro Falcato <pedro.falcato at gmail.com>
Sent: Wednesday, December 22, 2021 1:19 PM
To: edk2-devel-groups-io <devel at edk2.groups.io>; Kinney, Michael D <michael.d.kinney at intel.com>
Cc: Ard Biesheuvel <ardb at kernel.org>; Leif Lindholm <leif at nuviainc.com>; Sean Brogan <sean.brogan at microsoft.com>; Bret Barkelew <Bret.Barkelew at microsoft.com>; Kubacki, Michael <michael.kubacki at microsoft.com>
Subject: Re: [edk2-devel] spurious CI failures

I do find it weird that Chocolatey is taking 45 minutes to install Qemu. Is this normal? I've never used Chocolatey but I've used plenty of package managers and none have ever taken this long to install something.

Maybe it's Azure CI's problem?

Anyway, is it not possible to cross-build qemu, as detailed in https://wiki.qemu.org/Hosts/W32#Cross_builds_2, in order to avoid any package manager issues? In the case that it's the package manager's problem.

On Wed, Dec 22, 2021 at 8:27 PM Michael D Kinney <michael.d.kinney at intel.com<mailto:michael.d.kinney at intel.com>> wrote:
Hi Pedro,

Thanks for the link to the log.  I agree that log shows the choco install is very slow and timeout out after 45 minutes.

choco does support a flag to specify a larger timeout (--execution-timeout).  We can try increasing a bit higher as a temp workaround.

If choco is going to be this slow, we may have to use the caching features of CI agents to cache these types of downloads
so we only need to download when a version is updated.

Mike

From: devel at edk2.groups.io<mailto:devel at edk2.groups.io> <devel at edk2.groups.io<mailto:devel at edk2.groups.io>> On Behalf Of Pedro Falcato
Sent: Wednesday, December 22, 2021 11:22 AM
To: edk2-devel-groups-io <devel at edk2.groups.io<mailto:devel at edk2.groups.io>>; Kinney, Michael D <michael.d.kinney at intel.com<mailto:michael.d.kinney at intel.com>>
Cc: Ard Biesheuvel <ardb at kernel.org<mailto:ardb at kernel.org>>; Leif Lindholm <leif at nuviainc.com<mailto:leif at nuviainc.com>>; Sean Brogan <sean.brogan at microsoft.com<mailto:sean.brogan at microsoft.com>>; Bret Barkelew <Bret.Barkelew at microsoft.com<mailto:Bret.Barkelew at microsoft.com>>; Kubacki, Michael <michael.kubacki at microsoft.com<mailto:michael.kubacki at microsoft.com>>
Subject: Re: [edk2-devel] spurious CI failures

Hi Michael,

I was curious when I read this email this morning and I found a log: https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=36430&view=logs&j=417cab99-ad63-55d7-94dd-9898cfdbbe0e&t=5e8e03ff-365b-5151-1b77-4c25d18d4964
It looks like Chocolatey is taking way too long to download/install Qemu (it's taking more than 2700 seconds).

Best regards,
Pedro

On Wed, Dec 22, 2021 at 4:42 PM Michael D Kinney <michael.d.kinney at intel.com<mailto:michael.d.kinney at intel.com>> wrote:
Hi Ard,

Can you point me at some PRs that have this in their log?

Thanks,

Mike

> -----Original Message-----
> From: Ard Biesheuvel <ardb at kernel.org<mailto:ardb at kernel.org>>
> Sent: Wednesday, December 22, 2021 1:43 AM
> To: edk2-devel-groups-io <devel at edk2.groups.io<mailto:devel at edk2.groups.io>>
> Cc: Leif Lindholm <leif at nuviainc.com<mailto:leif at nuviainc.com>>; Kinney, Michael D <michael.d.kinney at intel.com<mailto:michael.d.kinney at intel.com>>; Sean Brogan <sean.brogan at microsoft.com<mailto:sean.brogan at microsoft.com>>;
> Bret Barkelew <Bret.Barkelew at microsoft.com<mailto:Bret.Barkelew at microsoft.com>>; Kubacki, Michael <michael.kubacki at microsoft.com<mailto:michael.kubacki at microsoft.com>>
> Subject: spurious CI failures
>
> Hello all,
>
> In one out of ~5 attempts at pushing a PR to master, I get a failure
> at the following step
>
> "Install QEMU and Set QEMU on path"
>
> of the PlatformCI_OvmfPkg_Windows_VS2019_PR target.
>
> Is there any way we can remediate this? Or at least classify some
> failures as temporary, so it doesn't look like the failure has
> anything to do with the contents of the PR?
>
> Alternatively, a control for maintainers to override bogus CI results
> would help as well.
>
> Thanks,
> Ard.





--
Pedro Falcato



--
Pedro Falcato


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85179): https://edk2.groups.io/g/devel/message/85179
Mute This Topic: https://groups.io/mt/87895116/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20211222/8bb0fcad/attachment.htm>


More information about the edk2-devel-archive mailing list