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

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

(+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.

Thanks
Laszlo