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@edk2.groups.io <devel@edk2.groups.io>
On Behalf Of Pedro Falcato
Sent: Wednesday, December 22, 2021 11:22 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Ard Biesheuvel <ardb@kernel.org>; Leif Lindholm <leif@nuviainc.com>; Sean Brogan <sean.brogan@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>; Kubacki, Michael <michael.kubacki@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@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@kernel.org>
> Sent: Wednesday, December 22, 2021 1:43 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io>
> Cc: Leif Lindholm <leif@nuviainc.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Sean Brogan <sean.brogan@microsoft.com>;
> Bret Barkelew <Bret.Barkelew@microsoft.com>; Kubacki, Michael <michael.kubacki@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