From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=M2a1KiPQ; spf=pass (domain: microsoft.com, ip: 40.107.82.127, mailfrom: sean.brogan@microsoft.com) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (NAM01-SN1-obe.outbound.protection.outlook.com [40.107.82.127]) by groups.io with SMTP; Fri, 20 Sep 2019 14:30:01 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IZnOQIHmJS06cn3WjclHMvL/K0TsHjgwojPzcK0NBKD+slaBR93F2yScwrJ8ESRhQOVHcjHK3plmZy0iAAbCxnNN7bt6Dyz6g13N5/bAmqiSwz3TQufOYwAhTYEIl/4G4VwX5ikxcUicU6IH//CT9iIXd2fyriI2M4dPN+FvxKLTk8snLW7zWYydnkYTC5d3ccZYau2q2P8XuhLQNGGILB9Vaf9/2DmUENNU3HC5qHRBzPrzXjnjvd9VCqdC30pn0Towy3bzYnFdjyyZAdsMFYvV36VJeXdoKw/v+TpUOelk+Ezt5uPG222X1vLntEmcAPl3RY1sr2bH5wdfwiRJHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2PT42T9mxwhAQBrYKIaCWkw8TlEd3i//lzCeRioV56U=; b=Ho6AYLpUe3odO3B9EBpJPdSgpIneNyr+R+i7CSA46m35b1ox2xamxBTfNEMw2l6qMYpPm3CTn1fcGPrfm7u4KWlHXZnyp9bg7V8Nz520NTGVyUGXVs6oAbr61M+eBox+6y/NizvljWLEqG5It63Bgd3X5+MOKJkTwmp/j6/RrymOePE9nIpo5BRiajiBRWO7WFCc+YydBdpS8tJtcocEEsbzV91cIIongZY0zukzOBJ8olcAAXjoqP4b2JTL1mOJIFC9s+Yr1j/YNBn4ZhGAS19Rh2UMB4Tyf3G0ka+HIHoByTnmjz/Zg9WFSrxYf4xdxO7tE+MxSB4VdWbbaS+ZSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2PT42T9mxwhAQBrYKIaCWkw8TlEd3i//lzCeRioV56U=; b=M2a1KiPQzPiWHw673XfGtc9PdpFEjH7DEfu2HPzZCcXYSa3SKGNnc+7pxOu/QPYV7zRQt6OFKNBHYrKKpfO4Vlc1HkRHXKJViES2zMkT5ktsNjN1uIGE9egMjFaArxHne+3oggE6X5V5mP1l/E1qatbwtfbPmh9hOf+BLapeubY= Received: from MW2PR2101MB1129.namprd21.prod.outlook.com (52.132.146.14) by MW2PR2101MB1115.namprd21.prod.outlook.com (52.132.149.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.10; Fri, 20 Sep 2019 21:29:58 +0000 Received: from MW2PR2101MB1129.namprd21.prod.outlook.com ([fe80::3443:b5d5:a879:48d6]) by MW2PR2101MB1129.namprd21.prod.outlook.com ([fe80::3443:b5d5:a879:48d6%3]) with mapi id 15.20.2284.007; Fri, 20 Sep 2019 21:29:58 +0000 From: "Sean" To: "Kinney, Michael D" , "devel@edk2.groups.io" , "rfc@edk2.groups.io" , "Kinney, Michael D" CC: Bret Barkelew Subject: Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1 Thread-Topic: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1 Thread-Index: AdVeooLjZu0dT/k9SsO41W96IKrh5AANWRwABBbvBeAAL11sMA== Date: Fri, 20 Sep 2019 21:29:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=sebrogan@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-09-20T21:29:56.3492390Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=06a981db-6f73-4626-8241-34fcbba6c80f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=sean.brogan@microsoft.com; x-originating-ip: [2001:4898:80e8:8:e0d5:855c:f865:532a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f3b3309-1684-4ec4-1d1b-08d73e11b029 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020);SRVR:MW2PR2101MB1115; x-ms-traffictypediagnostic: MW2PR2101MB1115:|MW2PR2101MB1115:|MW2PR2101MB1115: x-ms-exchange-transport-forked: True x-ms-exchange-purlcount: 12 x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0166B75B74 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(4636009)(346002)(396003)(376002)(39860400002)(366004)(136003)(199004)(189003)(13464003)(53546011)(305945005)(19627235002)(6506007)(64756008)(55016002)(2906002)(478600001)(66476007)(10290500003)(86362001)(71190400001)(6306002)(6246003)(8990500004)(186003)(476003)(46003)(4326008)(8676002)(52536014)(6116002)(25786009)(10090500001)(107886003)(99286004)(9686003)(81156014)(11346002)(446003)(8936002)(30864003)(66556008)(561944003)(102836004)(33656002)(5660300002)(74316002)(256004)(7696005)(44832011)(7736002)(81166006)(71200400001)(2201001)(66446008)(76176011)(966005)(2501003)(110136005)(76116006)(6436002)(22452003)(316002)(229853002)(14444005)(5024004)(486006)(14454004)(66946007)(579004);DIR:OUT;SFP:1102;SCL:1;SRVR:MW2PR2101MB1115;H:MW2PR2101MB1129.namprd21.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4OskjcyZN1o9tFvxjt/w5YSBwlfKQYJa80xfKjKQEyvDg5q48IIgmVY57wbvo+Ceyr/bJoqWXyjxw8AqaLODwXOAimyPcHK3eWQsGv2cn2HTZtCF1mOWbbYyRG+1J2ZXkefQbSeeLfs2iHqPlbWbRIFUUFLDRnsKEoJX9zA2rCG93Lj3eK5M8XDU1NdOORn/BKmO7ipMvzt89lPohekZst19qe2+rhBJ8RtdWafctq6hDsS47dyG1cN7n0p9GUR8EK3DpDkxJ9yrD1pD77pbMLdHHI0dLrwdwGn83uTiIW8nTyb+4Os35+AAOQrfIPfeQniDSGVQbN6JQfxZb/zk622uDX7qxOQvrwjY/ppqBa53fBIpT5a5WnJOMOYvSkZ1R6WxSujLOas3TLLJDV/NZWFBtuIiHixlLgHbBhEhtI8= MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f3b3309-1684-4ec4-1d1b-08d73e11b029 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2019 21:29:58.5925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wS1/72zboC1rrwnJu9VS8EJFjqWlICJDi4UC8YswV/ruGOk2rVMUqcF6nTTq5bRtM4dUea22Wm6hcuUuhVvmpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1115 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Currently it is building on Windows with VS2019. VS2017 would be trivial b= ut not worth it in my perspective given how aligned the two are. If you r= eally wanted to do a weekly or nightly build it could be added to that but = I have been focused on a PR build. I have a pipeline for GCC on linux. It doesn't' support host based unit t= ests but I am working to get the rest of the tests running. I do not have a pipeline for Mac or LLVM/Clang. That would be next and I = think your files below should help. To date we use PYTOOLs features to install our extra tools. This makes it= super easy and works for both local and server based builds. It gives str= ong versioning and management of that. It also tracks those versions and y= ou can see them on every build in the Built Tool Report artifact. It can = be downloaded here for html version. https://dev.azure.com/tianocore/edk2-c= i-play/_build/results?buildId=3D803&view=3Dartifacts. BUILD_TOOL_REPORT.h= tml Here it is pasted as plain text below. You can see the iasl and nasm vers= ions here.=20 Key Value Type TOOL_CHAIN_TAG VS2019 TOOL VC Version 14.22.27905 TOOL d:\a\1\s\Conf\build_rule.txt 1.04 INFO d:\a\1\s\Conf\target.txt 1.03 INFO d:\a\1\s\Conf\tools_def.txt 1.22 INFO iasl 20190215.0.0 INFO Mu-Basetools 2019.03.1 INFO mu_nasm 2.14.02 INFO Hope that helps.=20 I would be happy to queue up this topic for next design meeting and open i= t up to questions? I hope others would take a look prior to meeting. Thanks Sean -----Original Message----- From: Kinney, Michael D =20 Sent: Thursday, September 19, 2019 2:56 PM To: devel@edk2.groups.io; Sean Brogan ; rfc@edk= 2.groups.io; Kinney, Michael D Cc: Bret Barkelew Subject: RE: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1 Hi Sean, Which OS/Compiler configurations are currently enabled for the Code Compil= ation Test? I have been working on enabling multiple OS/Compiler configurations in Azu= re Pipelines. There are some tools that need to be installed for each of t= hese environments. Examples include NASM, iASL, Python. For the work you have done, how are these extra tools installed? Is it in= the YML files or in the Python scripts. One critical task is to identify the tools and their specific versions tha= t the CI system is configured to use. These configurations should be documented in a Wiki page and updated as ne= w tools are released and adopted by EDK II. The inventory of tools used to validate a release should Also be documente= d in a release notes for a stable tag. Here are the YML files that install the additional tools required to suppo= rt EDK II builds. I need the source and versions of these tools to be revi= ewed and approved. https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Fmdkinney%2Fedk2-ci%2Fblob%2Fmaster%2FAzurePipelines%2FWindowsPrerequ= isites.yml&data=3D02%7C01%7Csean.brogan%40microsoft.com%7C9e7d685fa1764= cf500af08d73d4c1e1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6370452694= 52466989&sdata=3DhM4AKoMutISI5Oc%2FeVMevx%2FVRUCjJHuhEwqom0R30Ak%3D&= ;reserved=3D0 https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Fmdkinney%2Fedk2-ci%2Fblob%2Fmaster%2FAzurePipelines%2FUbuntuPrerequi= sites.yml&data=3D02%7C01%7Csean.brogan%40microsoft.com%7C9e7d685fa1764c= f500af08d73d4c1e1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63704526945= 2466989&sdata=3DKQ2zas2bJ%2FCjSRWGyMrxq5Rk4cW5lOgXQNR99QJbEKY%3D&re= served=3D0 https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Fmdkinney%2Fedk2-ci%2Fblob%2Fmaster%2FAzurePipelines%2FMacOsPrerequis= ites.yml&data=3D02%7C01%7Csean.brogan%40microsoft.com%7C9e7d685fa1764cf= 500af08d73d4c1e1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045269452= 466989&sdata=3DOzAmzYkRJ3rQOHEDgKTREz%2BNp7acOWUACh1s%2Fb4UPGk%3D&r= eserved=3D0 Thanks, Mike > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Sean=20 > via Groups.Io > Sent: Thursday, August 29, 2019 7:22 PM > To: rfc@edk2.groups.io; Kinney, Michael D=20 > ; devel@edk2.groups.io > Cc: Bret Barkelew > Subject: Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1 >=20 > Mike, as you mentioned we have been working towards enabling a=20 > practical and extensible CI for Edk2 using Azure dev ops and the=20 > recently added edk2-pytool infrastructure. We have been using similar= =20 > CI for Project Mu for the last few years. >=20 > Our approach is a little different in that we focus on validating the=20 > whole code base rather than just the incoming patch. We do this=20 > because we have found unexpected consequences of patches and overall=20 > we want all code to be compliant not just new additions. We have=20 > found the time to test the whole tree is not much longer than only the= =20 > parts impacted by a code change (except maybe when running the entire=20 > compile test on every package). This obviously comes with an initial=20 > tax of needing to get the codebase into compliant form. > Anyway we have prepared an RFC in addition to yours and would like to=20 > see these two efforts merged together. >=20 > We are still working on making a few optimizations. > Currently if the full set of tests are run we take about 20 minutes. > This is because compiling MdeModulePkg for debug, release, and host=20 > based tests take a while. Most other packages are in the 10 minute=20 > range. We do have easy ways to disable or limit certain tests as well= =20 > as expand the matrix to leverage more cloud resources (more parallel=20 > builds). >=20 >=20 > Content is best viewed online with links to helpful content but is=20 > also attached below: > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgith > ub.com%2Fspbrogan%2Fedk2-staging%2Fblob%2Fedk2-&data=3D02%7C01%7Csea > n.brogan%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf > 86f141af91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DxOiPHH > VbMhFBsIpj%2F9mhOhrkhdsF2Gbehd6%2Frk0XYgM%3D&reserved=3D0 > stuart-ci-latest/Readme-CI-RFC.md >=20 > # CI and PR Gates >=20 > ## Background >=20 > Historically, while the TianoCore maintainers and stewards have done a= =20 > fantastic job of keeping contribution policies consistent and=20 > contributions clean and well-documented, there have been few processes= =20 > that ran to verify the sanity, cleanliness, and efficacy of the=20 > codebase, and even fewer that publicly published their results for the= =20 > community at large. This has caused inconsistancies and issues within=20 > the codebase from time to time. >=20 > Adding continuous integration (and potentially PR > gates) to the checkin process ensures that simple errors like these=20 > are caught and can be fixed on a regular basis. >=20 > ## Strategy >=20 > While a number of CI solutions exist, this proposal will focus on the=20 > usage of Azure Dev Ops and Build Pipelines. For demonstration, a=20 > sample [TianoCore > repo](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F% > 2Fgithub.com%2Fspbrogan%2Fedk2-staging.git&data=3D02%7C01%7Csean.bro > gan%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f14 > 1af91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DQmzQhemLUNB > 7FGJwoGeeewExThrUjUArxnkmtro1b8A%3D&reserved=3D0) > (branch edk2-stuart-ci-latest) and [Dev Ops > Pipeline](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A > %2F%2Fdev.azure.com%2Ftianocore%2Fedk2-ci-&data=3D02%7C01%7Csean.bro > gan%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f14 > 1af91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DrS%2FrjIFkS > uEhI%2FDWyslf34i711%2FbY8Gw%2Byexq%2FwydjU%3D&reserved=3D0 > play/_build?definitionId=3D12) have been set up. >=20 > Furthermore, this proposal will leverage the TianoCore python tools=20 > PIP modules: > [library](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A > %2F%2Fpypi.org%2Fproject%2Fedk2-pytool-&data=3D02%7C01%7Csean.brogan > %40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141af > 91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DjzM6MKZFFAEvyR > 4h0%2Bkf5pUcBSsoVzkIHFFi1Bd6Il4%3D&reserved=3D0 > library/) and > [extensions](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps > %3A%2F%2Fpypi.org%2Fproject%2Fedk2-pytool-&data=3D02%7C01%7Csean.bro > gan%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f14 > 1af91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DjzM6MKZFFAE > vyR4h0%2Bkf5pUcBSsoVzkIHFFi1Bd6Il4%3D&reserved=3D0 > extensions/) (with repos located > [here](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F > %2Fgithub.com%2Ftianocore%2Fedk2-pytool-&data=3D02%7C01%7Csean.broga > n%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141a > f91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DOwT%2BiNTN9Rv > r14Oj67IdDlK8WGJClTIsmEzdyrBt2Ho%3D&reserved=3D0 > library) and=20 > [here](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F > %2Fgithub.com%2Ftianocore%2Fedk2-&data=3D02%7C01%7Csean.brogan%40mic > rosoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141af91ab2d > 7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DtInVwGwCXXGBgcmHQ%2B > 0UwRaEbtZWRy8hTp5wpRtN0R0%3D&reserved=3D0 > pytool-extensions)). >=20 > The primary execution flows can be found in the `azure-=20 > pipelines-pr-gate.yml` and `azure-pipelines-pr-gate- linux.yml` files.= =20 > These YAML files are consumed by the Azure Dev Ops Build Pipeline and=20 > dictate what server resources should be used, how they should be=20 > configured, and what processes should be run on them. > An overview of this schema can be found > [here](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F > %2Fdocs.microsoft.com%2Fen-&data=3D02%7C01%7Csean.brogan%40microsoft > .com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C637045269452466989&sdata=3Dj8nyYG3VnizwKFZ8l1BWoLcPy% > 2BuaSoVT0jN2Esi7wH8%3D&reserved=3D0 > us/azure/devops/pipelines/yaml-schema?view=3Dazure- > devops&tabs=3Dschema). >=20 > Inspection of these files reveals the EDKII Tools commands that make=20 > up the primary processes for the CI > build: 'stuart_setup', 'stuart_update', and 'stuart_ci_build'. These=20 > commands come from the EDKII Tools PIP modules and are configured as=20 > described below. More documentation on the stuart tools can be found=20 > [here](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F > %2Fgithub.com%2Ftianocore%2Fedk2-pytool-&data=3D02%7C01%7Csean.broga > n%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141a > f91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DOwT%2BiNTN9Rv > r14Oj67IdDlK8WGJClTIsmEzdyrBt2Ho%3D&reserved=3D0 > extensions/blob/master/docs/using.md) and > [here](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F > %2Fgithub.com%2Ftianocore%2Fedk2-pytool-&data=3D02%7C01%7Csean.broga > n%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141a > f91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DOwT%2BiNTN9Rv > r14Oj67IdDlK8WGJClTIsmEzdyrBt2Ho%3D&reserved=3D0 > extensions/blob/master/docs/features/feature_invocables > .md). >=20 > ## Configuration >=20 > Configuration of the CI process consists of (in order of precedence): > * command-line arguments passed in via the Pipeline YAML > * a per-package configuration file (e.g. ` name>.mu.yaml`) that is detected by the CI system in > EDKII Tools. > * a global configuration Python module (e.g. > `CISetting.py`) passed in via the command-line >=20 > The global configuration file is described in [this > readme](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2 > F%2Fgithub.com%2Ftianocore%2Fedk2-pytool-&data=3D02%7C01%7Csean.brog > an%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141 > af91ab2d7cd011db47%7C1%7C0%7C637045269452466989&sdata=3DOwT%2BiNTN9R > vr14Oj67IdDlK8WGJClTIsmEzdyrBt2Ho%3D&reserved=3D0 > extensions/blob/master/docs/usability/using_settings_ma > nager.md) from the EDKII Tools documentation. This configuration is=20 > written as a Python module so that decisions can be made dynamically=20 > based on command line parameters and codebase state. >=20 > The per-package configuration file can override most settings in the=20 > global configuration file, but is not dynamic. This file can be used=20 > to skip or customize tests that may be incompatible with a specific=20 > package. > By default, the global configuration will try to run all tests on all=20 > packages. >=20 > ## CI Test Types >=20 > All CI tests are instances of EDKII Tools plugins. > Documentation on the plugin system can be found > [here](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F > %2Fgithub.com%2Ftianocore%2Fedk2-pytool-&data=3D02%7C01%7Csean.broga > n%40microsoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141a > f91ab2d7cd011db47%7C1%7C0%7C637045269452476994&sdata=3D1AM4geY%2BEFh > ekun7oQOYyVVt%2Bwn6CAF2hhtkS0sgwPU%3D&reserved=3D0 > extensions/blob/master/docs/usability/using_plugin_mana > ger.md) and=20 > [here](https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F > %2Fgithub.com%2Ftianocore%2Fedk2-&data=3D02%7C01%7Csean.brogan%40mic > rosoft.com%7C9e7d685fa1764cf500af08d73d4c1e1b%7C72f988bf86f141af91ab2d > 7cd011db47%7C1%7C0%7C637045269452476994&sdata=3D3vyPMvrfG3V4doNM0%2B > cKTpDSHEEEvkfxKAtw3eiJWsY%3D&reserved=3D0 > pytool- > extensions/blob/master/docs/features/feature_plugin_man > ager.md). Upon invocation, each plugin will be passed the path to the=20 > current package under test and a dictionary containing its targeted=20 > configuration, as assembled from the command line, per-package=20 > configuration, and global configuration. >=20 > Note: CI plugins are considered unique from build plugins and helper=20 > plugins, even though some CI plugins may execute steps of a build. >=20 > In the example, these plugins live alongside the code under test (in=20 > the `BaseTools` directory), but may be moved to the 'edk2-test' repo=20 > if that location makes more sense for the community. >=20 > ### Module Inclusion Test - DscCompleteCheck >=20 > This test scans all available modules (via INF files) and compares=20 > them to the package-level DSC file for the package each module is=20 > contained within. The test considers it an error if any module does=20 > not appear in the `Components` section of at least one package-level=20 > DSC (indicating that it would not be built if the package were built). >=20 > ### Code Compilation Test - CompilerPlugin >=20 > Once the Module Inclusion Test has verified that all modules would be=20 > built if all package-level DSCs were built, the Code Compilation Test=20 > simply runs through and builds every package-level DSC on every=20 > toolchain and for every architecture that is supported. Any module=20 > that fails to build is considered an error. >=20 > ### Host-Based UnitTests - HostUnitTestCompilerPlugin and=20 > HostUnitTestDscCompleteCheck >=20 > The [Testing RFC doc](Readme-Testing-RFC.md) has much more detail on=20 > this, but the basic idea is that host- based unit tests can be=20 > compiled against individual modules and libraries and run on the build= =20 > agent (in this case, the Dev Ops build server). The successful and=20 > failing test case results are collected and included in the final=20 > build report. >=20 > ### GUID Uniqueness Test - GuidCheck >=20 > This test works on the collection of all packages rather than an=20 > individual package. It looks at all FILE_GUIDs and GUIDs declared in=20 > DEC files and ensures that they are unique for the codebase. This=20 > prevents, for example, accidental duplication of GUIDs when using an=20 > existing INF as a template for a new module. >=20 > ### Cross-Package Dependency Test - DependencyCheck >=20 > This test compares the list of all packages used in INFs files for a=20 > given package against a list of "allowed dependencies" in plugin=20 > configuration for that package. Any module that depends on a=20 > disallowed package will cause a test failure. >=20 > ### Library Declaration Test - LibraryClassCheck >=20 > This test looks at all library header files found in a package's=20 > `Include/Library` directory and ensures that all files have a matching= =20 > LibraryClass declaration in the DEC file for the package. Any missing=20 > declarations will cause a failure. >=20 > ### Invalid Character Test - CharEncodingCheck >=20 > This test scans all files in a package to make sure that there are no=20 > invalid Unicode characters that may cause build errors in some=20 > character sets/localizations. >=20 > ## Next Steps >=20 > * Receive community feedback on RFC. > * Determine where this phase makes sense given existing RFCs from=20 > other TianoCore contributors. > * Optimize testing beharior. > * Only run a subset of tests on PRs or individual commits. > * Run full testing either once per day or once every several=20 > commits. > * Add more tests/capabilities. > * Continue to improve results formatting. > * Continue to improve CI documentation. > * Much of this documentation effort is pending community feedback on= =20 > which parts are needed and what phases are priorities. >=20 > Thanks >=20 >=20 > -----Original Message----- > From: rfc@edk2.groups.io On Behalf Of Michael D=20 > Kinney via Groups.Io > Sent: Thursday, August 29, 2019 1:23 PM > To: devel@edk2.groups.io; rfc@edk2.groups.io > Subject: [edk2-rfc] [RFC] EDK II Continuous Integration Phase 1 >=20 > Hello, >=20 > This is a proposal for a first step towards continuous integration for= =20 > all TianoCore repositories to help improve to quality of commits and=20 > automate testing and release processes for all EDK II packages and=20 > platforms. >=20 > This is based on work from a number of EDK II community members that=20 > have provide valuable input and evaluations. >=20 > * Rebecca Cran Jenkins evaluation > * Laszlo Ersek GitLab evaluation > * Philippe Mathieu-Daud=E9 GitLab evaluation > * Sean Brogan Azure Pipelines and=20 > HBFA > * Bret Barkelew > Azure Pipelines and HBFA > * Jiewen Yao HBFA >=20 > The following link is a link to an EDK II WIKI page that contains a=20 > summary of the work to date. Please provide feedback in the EDK II=20 > mailing lists. The WIKI pages will be updated with input from the=20 > entire EDK II community. >=20 >=20 > https://nam06.safelinks.protection.outlook.com/?url=3Dhtt > ps%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io > %2Fwiki%2FEDK-II-Continuous- > Integration&data=3D02%7C01%7Csean.brogan%40microsoft. > com%7C6f67f169a6c746b4288608d72cbea7b6%7C72f988bf86f141 > af91ab2d7cd011db47%7C1%7C0%7C637027069686644659&sda > ta=3DGR9wN6gP3mJlCTopAaQ2rlzhby1nuF%2BwDVsfFIQAZjA%3D& > ;reserved=3D0 >=20 > Proposal > =3D=3D=3D=3D=3D=3D=3D=3D > Phase 1 of adding continuous integration is limited to the > edk2 repository. Additional repositories will be added later. >=20 > The following changes are proposed: > * Remove EDK II Maintainers write access to edk2 repository. > Only EDK II Administrators will continue to have write > access, and that should only be used to handle extraordinary > events. > * EDK II Maintainers use a GitHub Pull Request instead of push > to commit a patch series to the edk2 repository. > There are > no other changes to the development and review process. The > patch series is prepared in an EDK II maintainer branch with > all commit message requirements met on each patch in the series. > * The edk2 repository only accepts Pull Requests from members > of the EDK II Maintainers team. Pull Requests from anyone else > are rejected. > * Run pre-commit checks using Azure Pipelines > * If all pre-commit checks pass, then the patch series is auto > committed. The result of this commit must match the contents > and commit history that would have occurred using the previous > push operation. > * If any pre-commit checks fail, then notify the submitter. > A typical reason for a failure would be a merge conflict with > another pull request that was just processed. > * Limit pre-commit checks execution time to 10 minutes. > * Provide on-demand builds to EDK II Maintainers that to allow > EDK II Maintainers to submit a branch through for the same > set of pre-commit checks without submitting a pull request. >=20 > ## Pre-Commit Checks in Phase 1 > * Run and pass PatchCheck.py with no errors >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > The following are some additional pre-commit check > ideas that could be quickly added once the initial > version using PatchCheck.py is fully functional. > Please provide feedback on the ones you like and > additional ones you think may improve the quality of > the commits to the edk2 repository. >=20 > ## Proposed Pre-Commit Checks in Phase 2 > * Verify Reviewed-by and Acked-by tags are present with > correct maintainer email addresses > * Verify no non-ASCII characters in modified files > * Verify no binary files in set of modified files > * Verify package dependency rules in modified files >=20 > ## Proposed Pre-Commit Checks in Phase 3 > * Run ECC on modified files > * Verify modified modules/libs build > * Run available host based tests (HBFA) against > modified > modules/libs >=20 > Best regards, >=20 > Mike >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20