From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) by mx.groups.io with SMTP id smtpd.web11.12893.1585319832510637569 for ; Fri, 27 Mar 2020 07:37:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iz3zj5xY; spf=pass (domain: redhat.com, ip: 63.128.21.74, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585319831; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gF2gvHPBJSUKaPP30b9Q9koC9wMvGVrzn/40iWIRuHQ=; b=iz3zj5xYO3hNQp2szmZgJAV/n6U6CjPJk5M/ks/xHXLHugtic79CH6siD8KmrqLDEXtb5I LVpWYc1QzqH1R3VEZB/68T0nNHFoxTMjYIKmR/2wnw6WJliIX0xNDlFKDTDUvuQH2fVG9t dsEEpKzAAOyT/OK0uqgNQfDBxrqfSko= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-346-U1VR6YbbO626xU5LZaJthQ-1; Fri, 27 Mar 2020 10:37:02 -0400 X-MC-Unique: U1VR6YbbO626xU5LZaJthQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 44CBC802570; Fri, 27 Mar 2020 14:37:01 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-36.ams2.redhat.com [10.36.114.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4B03919488; Fri, 27 Mar 2020 14:36:59 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg To: devel@edk2.groups.io, ard.biesheuvel@linaro.org, "Zhang, Shenglei" Cc: Sean Brogan , Bret Barkelew , Michael D Kinney , Liming Gao , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Anthony Perard References: <20200326070418.25824-1-shenglei.zhang@intel.com> From: "Laszlo Ersek" Message-ID: <896ef5b0-8487-3cba-8472-5a210b00fe8d@redhat.com> Date: Fri, 27 Mar 2020 15:36:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit (+Phil, +Anthony) On 03/26/20 09:43, Ard Biesheuvel wrote: > (+ Laszlo) > > On Thu, 26 Mar 2020 at 08:04, Zhang, Shenglei 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 >> Cc: Bret Barkelew >> Cc: Michael D Kinney >> Cc: Liming Gao >> Signed-off-by: Shenglei Zhang > > 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