Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg

["Laszlo Ersek" <lersek@redhat.com>]

On 03/27/20 15:36, Laszlo Ersek wrote:
> (+Phil, +Anthony)
> 
> On 03/26/20 09:43, Ard Biesheuvel wrote:
>> (+ Laszlo)
>>
>> On Thu, 26 Mar 2020 at 08:04, Zhang, Shenglei <shenglei.zhang@intel.com> wrote:
>>>
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2570
>>> OvmfPkg and EmulatorPkg are mostly used by the developers, so add
>>> them to target list.
>>>
>>> Cc: Sean Brogan <sean.brogan@microsoft.com>
>>> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
>>> Cc: Michael D Kinney <michael.d.kinney@intel.com>
>>> Cc: Liming Gao <liming.gao@intel.com>
>>> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
>>
>> Could we add ArmVirtPkg as well please? Also, which .DSCs are built
>> inside OvmfPkg/ with this change?
> 
> Thanks for the CC.
> 
> (1) Having learned that Sean and probably others do not benefit from
> OvmfPkg, I do not wish to slow down PR gating for them, by making OVMF
> builds a mandatory part of CI -- as long as the PR does not have a patch
> that modifies OvmfPkg itself.
> 
> (I'm unsure if the above behavior is already ensured by the CI system --
> if it is, then I'm sorry about the noise.)
> 
> Same applies (from my perspective) to ArmVirtPkg.
> 
> Obviously, I would definitely *like* if ArmVirtPkg / OvmfPkg builds were
> a constant, mandatory part of CI, but I totally realize it would put an
> unjustified burden on contributors that do not care about those
> platforms at all -- especially given that the core package(s) being
> patched -- such as NetworkPkg -- *are* test-built by CI in isolation anyway.
> 
> 
> (2) In case the PR does modify OvmfPkg, and so the platform builds are
> required, I would like the builds to cover more ground:
> 
> (2a) DEBUG, RELEASE and NOOPT should all be covered,
> 
> (2b) Ia32, Ia32X64, and X64 should all be covered.
> 
> (I've CC'd Anthony so he can speak to the "OvmfXen.dsc" build configs.)
> 
> (2c) For each of the three platforms I mention in (2b), there should be
> a "bare bones" (default) build, but also a reasonably "full-blown" build.
> 
> - Bare-bones build:
> 
>   -D FD_SIZE_2MB
> 
> (This is so that the default (bare-bones) configuration continue to fit
> in the (arguably legacy) 2MB FD.)
> 
> - Full-blown build:
> 
>   -D SECURE_BOOT_ENABLE \
>   -D SMM_REQUIRE \
>   -D TPM_ENABLE \
>   -D TPM_CONFIG_ENABLE \
>   -D NETWORK_TLS_ENABLE \
>   -D NETWORK_IP6_ENABLE \
>   -D NETWORK_HTTP_BOOT_ENABLE
> 
> Note that this will require the OpenSSL submodule to be initialized.
> 
> This means 3 * 3 * 2 = 18 builds thus far.
> 
> 
> (3) ArmVirtPkg platforms should be built if either OvmfPkg or ArmVirtPkg
> is modified.
> 
> Personally I'd like the ArmVirtQemu platform to be built, but Ard and
> Anthony will likely ask for more.
> 
> For ArmVirtQemu, because we have no (i) different FD sizes, nor (b) an
> SMM stack that makes some drivers strictly exclusive with other drivers,
> I think we should simply aim at the most comprehensive build:
> 
> (3a) DEBUG, RELEASE and NOOPT,
> 
> (3b) Options:
> 
>   -D SECURE_BOOT_ENABLE \
>   -D TPM2_ENABLE \
>   -D TPM2_CONFIG_ENABLE \
>   -D NETWORK_IP6_ENABLE \
>   -D NETWORK_HTTP_BOOT_ENABLE \
>   -D NETWORK_TLS_ENABLE
> 
> This means +3 builds (21 builds in total) from my perspective.

... to be clear: the above is my "wish list".

If, at the moment, we can enable OvmfPkg and ArmVirtPkg builds in any
shape or form whatsoever, that's already an improvement! So my comments
are not to be taken as disagreement with the currently proposed patch.
I'm just describing how I believe we should do these builds eventually.

Thanks
Laszlo