From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@microsoft.com header.s=selector1 header.b=YT9+XGWY; spf=pass (domain: microsoft.com, ip: 40.107.71.136, mailfrom: sean.brogan@microsoft.com) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (NAM05-BY2-obe.outbound.protection.outlook.com [40.107.71.136]) by groups.io with SMTP; Thu, 29 Aug 2019 19:21:40 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g52/3Yv1uLIW+yCyVYEAqbc6oY4Y3/tKq0Y6ayzIjHZs3BC4+OeDGWKstpzrLw8H17WDyh7norTJGs5BIgzTqhnvE/8+CgrDkuTePeF9Gx9pA19J+9t/qdd+LcXOt7gvoe6/EGqBKiJ/WspYec1MC4sJ9KkSN0Rjv5ZvBepAHUsO/eebzf4469Er815x8yrAxgujN98a0MptqGm7KLQrD8dGagaDNQlyIyP/AEaTKjP+eL7eh0dsMXXUzGErWxMcqayQBUQZ6j1ZuVOexs5LYx/krYr97XCr/h2pRs6XDh4olugVjIJi6ImLab460TGpnVQRQ1kCTYngOHAHkPqTLA== 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=mAwn3OWDcs/sLJu2eNm5lq2of36fOCJGXZNrG/JwJOU=; b=bPfvO9L/foNk2G7YcS3IWBRyS5oAoWD5kkCYySXX6zsMguZokun34WjY9gw64qV+qI17W8Rci18ozVPFjOv8fsIT0zPHbn7eOSPTXwtJJeQcXyJ9a/RNEGot/eTmzXARWtXxRm9wdd9O/vUsSLk6Pl6htbVBqZS/6BMhhMRLIYm8KrilH0iMMwIye/hjJ+CeGSidMgqmm66G8wRNge1bj0mu7CeV3vIHvVm3rv+JI2hNLtyHUSpZhKxjvsxGYIBE/HvM2rDKccR4mj+sT5gna8LGAerDp21wO1aoTuegns/BsytGiWYcAUjRwwH4c6f7pLtbIwiJ8efLD/vBh6Yvvw== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mAwn3OWDcs/sLJu2eNm5lq2of36fOCJGXZNrG/JwJOU=; b=YT9+XGWYy7rptGlfRlYFLZi0w5ZEVhUYATuvnPuHEip6jAtiVgbmhvtOHQCZqNAoNefJIi8Ulw5GTfk4qJ73BtbZ9BSLj1SpmHlPWUPwj8t1T9nvuOfmlk4LccPqJzalDJ9E4KamUoICFrFLQEOvxUe0UF/3j84DWgQ/xmxMZ48= Received: from DM5PR21MB0842.namprd21.prod.outlook.com (10.173.172.140) by DM5PR21MB0825.namprd21.prod.outlook.com (10.173.172.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.1; Fri, 30 Aug 2019 02:21:38 +0000 Received: from DM5PR21MB0842.namprd21.prod.outlook.com ([fe80::b1cc:7aac:ffb6:1dae]) by DM5PR21MB0842.namprd21.prod.outlook.com ([fe80::b1cc:7aac:ffb6:1dae%13]) with mapi id 15.20.2241.000; Fri, 30 Aug 2019 02:21:38 +0000 From: "Sean" To: "rfc@edk2.groups.io" , "Kinney, Michael D" , "devel@edk2.groups.io" CC: Bret Barkelew Subject: Re: [RFC] EDK II Continuous Integration Phase 1 Thread-Topic: [RFC] EDK II Continuous Integration Phase 1 Thread-Index: AdVeooLjZu0dT/k9SsO41W96IKrh5AANWRwA Date: Fri, 30 Aug 2019 02:21:38 +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-08-30T02:21:36.2716914Z; 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=6aa9c4f9-628e-4d13-b073-c52bca9338b7; 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:a:4174:2f8c:11ba:51c4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 132de9f3-3a3d-4b2c-aa0b-08d72cf0c9d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020);SRVR:DM5PR21MB0825; x-ms-traffictypediagnostic: DM5PR21MB0825:|DM5PR21MB0825:|DM5PR21MB0825: x-ms-exchange-transport-forked: True x-ms-exchange-purlcount: 17 x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(4636009)(396003)(39860400002)(136003)(376002)(346002)(366004)(199004)(189003)(13464003)(107886003)(66556008)(64756008)(76176011)(66476007)(66446008)(5024004)(53546011)(76116006)(6436002)(99286004)(102836004)(7696005)(14444005)(6506007)(44832011)(6306002)(561944003)(66946007)(22452003)(446003)(476003)(11346002)(46003)(8936002)(486006)(5660300002)(229853002)(316002)(110136005)(7736002)(478600001)(25786009)(10090500001)(55016002)(52536014)(256004)(186003)(53936002)(8676002)(6116002)(966005)(71200400001)(8990500004)(71190400001)(305945005)(30864003)(4326008)(9686003)(2501003)(74316002)(81156014)(2906002)(10290500003)(14454004)(6246003)(86362001)(81166006)(33656002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM5PR21MB0825;H:DM5PR21MB0842.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: i4OGqCTThlvAAddzUZe8oLlyMK6+1g9qnhlGFhPChV0IiUq6XS0U6DfRzGZqNXnhUdEzgrZquAvvVSM51CYEsvIEC8Zk72aRfYDdvTWaygJsRPcGGUjB6RlCHqt/7JTDrX06qo7A5HmC+WtDqdXdUFyuJaIR/de/LiWWqkPQ22N7yS0MaJ8zTUmniV3IPTBkTdsTBxiZvOdgW5paryeRyOI2Fed+jlyO5zA3y/EUfSvmECrvthYOBZ5TQy0xSuW4hb9bhXa2NOnIY7LM7p61eMSXAP6/GBdPG4A+tA/3HxzbpItVNm50cD/pZjXhRK20J6ikMPis0iuckbot84SW5mozSUwvOtKh013Hs8lqlUZpgr/6YMrMzmvMmDNoP3UGTMblPYXF9is/ssewMX4c7Hm3HkfnIFMpZ+d3nRNAQd0= MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 132de9f3-3a3d-4b2c-aa0b-08d72cf0c9d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 02:21:38.5485 (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: 5T0cpG2J7fWLPDLxlQs7exxHf9A/M4HHOcgfYY8m18nV/c1clHiEG2A3xSWOaPvOUHlZtKud5K5n86aNfU70dA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0825 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mike, as you mentioned we have been working towards enabling a practical an= d extensible CI for Edk2 using Azure dev ops and the recently added edk2-py= tool infrastructure. We have been using similar CI for Project Mu for the = last few years. Our approach is a little different in that we focus on validating the whol= e code base rather than just the incoming patch. We do this because we hav= e found unexpected consequences of patches and overall we want all code to = be compliant not just new additions. We have found the time to test the wh= ole tree is not much longer than only the parts impacted by a code change (= except maybe when running the entire compile test on every package). This = obviously comes with an initial tax of needing to get the codebase into com= pliant form. Anyway we have prepared an RFC in addition to yours and would= like to see these two efforts merged together. 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 based tests take a while. Most o= ther packages are in the 10 minute range. We do have easy ways to disable = or limit certain tests as well as expand the matrix to leverage more cloud = resources (more parallel builds). =20 Content is best viewed online with links to helpful content but is also at= tached below: =20 https://github.com/spbrogan/edk2-staging/blob/edk2-stuart-ci-latest/Readme= -CI-RFC.md=20 # CI and PR Gates ## Background Historically, while the TianoCore maintainers and stewards have done a fan= tastic job of keeping contribution policies consistent and contributions cl= ean and well-documented, there have been few processes that ran to verify t= he sanity, cleanliness, and efficacy of the codebase, and even fewer that p= ublicly published their results for the community at large. This has caused= inconsistancies and issues within the codebase from time to time. Adding continuous integration (and potentially PR gates) to the checkin pr= ocess ensures that simple errors like these are caught and can be fixed on = a regular basis. ## Strategy While a number of CI solutions exist, this proposal will focus on the usag= e of Azure Dev Ops and Build Pipelines. For demonstration, a sample [TianoC= ore repo](https://github.com/spbrogan/edk2-staging.git) (branch edk2-stuart= -ci-latest) and [Dev Ops Pipeline](https://dev.azure.com/tianocore/edk2-ci-= play/_build?definitionId=3D12) have been set up. Furthermore, this proposal will leverage the TianoCore python tools PIP mo= dules: [library](https://pypi.org/project/edk2-pytool-library/) and [extens= ions](https://pypi.org/project/edk2-pytool-extensions/) (with repos located= [here](https://github.com/tianocore/edk2-pytool-library) and [here](https:= //github.com/tianocore/edk2-pytool-extensions)). The primary execution flows can be found in the `azure-pipelines-pr-gate.y= ml` and `azure-pipelines-pr-gate-linux.yml` files. These YAML files are con= sumed by the Azure Dev Ops Build Pipeline and dictate what server resources= should be used, how they should be configured, and what processes should b= e run on them. An overview of this schema can be found [here](https://docs.= microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=3Dazure-devops&= tabs=3Dschema). Inspection of these files reveals the EDKII Tools commands that make up th= e primary processes for the CI build: 'stuart_setup', 'stuart_update', and = 'stuart_ci_build'. These commands come from the EDKII Tools PIP modules and= are configured as described below. More documentation on the stuart tools = can be found [here](https://github.com/tianocore/edk2-pytool-extensions/blo= b/master/docs/using.md) and [here](https://github.com/tianocore/edk2-pytool= -extensions/blob/master/docs/features/feature_invocables.md). ## Configuration 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. `.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 The global configuration file is described in [this readme](https://github= .com/tianocore/edk2-pytool-extensions/blob/master/docs/usability/using_sett= ings_manager.md) from the EDKII Tools documentation. This configuration is = written as a Python module so that decisions can be made dynamically based = on command line parameters and codebase state. The per-package configuration file can override most settings in the globa= l configuration file, but is not dynamic. This file can be used to skip or = customize tests that may be incompatible with a specific package. By defaul= t, the global configuration will try to run all tests on all packages. ## CI Test Types All CI tests are instances of EDKII Tools plugins. Documentation on the pl= ugin system can be found [here](https://github.com/tianocore/edk2-pytool-ex= tensions/blob/master/docs/usability/using_plugin_manager.md) and [here](htt= ps://github.com/tianocore/edk2-pytool-extensions/blob/master/docs/features/= feature_plugin_manager.md). Upon invocation, each plugin will be passed the= path to the current package under test and a dictionary containing its tar= geted configuration, as assembled from the command line, per-package config= uration, and global configuration. Note: CI plugins are considered unique from build plugins and helper plugi= ns, even though some CI plugins may execute steps of a build. In the example, these plugins live alongside the code under test (in the `= BaseTools` directory), but may be moved to the 'edk2-test' repo if that loc= ation makes more sense for the community. ### Module Inclusion Test - DscCompleteCheck This test scans all available modules (via INF files) and compares them to= the package-level DSC file for the package each module is contained within= . The test considers it an error if any module does not appear in the `Comp= onents` section of at least one package-level DSC (indicating that it would= not be built if the package were built). ### Code Compilation Test - CompilerPlugin Once the Module Inclusion Test has verified that all modules would be buil= t if all package-level DSCs were built, the Code Compilation Test simply ru= ns through and builds every package-level DSC on every toolchain and for ev= ery architecture that is supported. Any module that fails to build is consi= dered an error. ### Host-Based UnitTests - HostUnitTestCompilerPlugin and HostUnitTestDscC= ompleteCheck The [Testing RFC doc](Readme-Testing-RFC.md) has much more detail on this,= but the basic idea is that host-based unit tests can be compiled against i= ndividual modules and libraries and run on the build agent (in this case, t= he Dev Ops build server). The successful and failing test case results are = collected and included in the final build report. ### GUID Uniqueness Test - GuidCheck This test works on the collection of all packages rather than an individua= l package. It looks at all FILE_GUIDs and GUIDs declared in DEC files and e= nsures that they are unique for the codebase. This prevents, for example, a= ccidental duplication of GUIDs when using an existing INF as a template for= a new module. ### Cross-Package Dependency Test - DependencyCheck This test compares the list of all packages used in INFs files for a given= package against a list of "allowed dependencies" in plugin configuration f= or that package. Any module that depends on a disallowed package will cause= a test failure. ### Library Declaration Test - LibraryClassCheck This test looks at all library header files found in a package's `Include/= Library` directory and ensures that all files have a matching LibraryClass = declaration in the DEC file for the package. Any missing declarations will = cause a failure. ### Invalid Character Test - CharEncodingCheck This test scans all files in a package to make sure that there are no inva= lid Unicode characters that may cause build errors in some character sets/l= ocalizations. ## Next Steps * Receive community feedback on RFC. * Determine where this phase makes sense given existing RFCs from other Ti= anoCore 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 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 whi= ch parts are needed and what phases are priorities. Thanks -----Original Message----- From: rfc@edk2.groups.io On Behalf Of Michael D Kinne= y 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 Hello, This is a proposal for a first step towards continuous integration for all= TianoCore repositories to help improve to quality of commits and automate = testing and release processes for all EDK II packages and platforms. This is based on work from a number of EDK II community members that have = provide valuable input and evaluations. * Rebecca Cran Jenkins evaluation * Laszlo Ersek GitLab evaluation * Philippe Mathieu-Daud=E9 GitLab evaluation * Sean Brogan Azure Pipelines and HBFA * Bret Barkelew Azure Pipelines and H= BFA * Jiewen Yao HBFA The following link is a link to an EDK II WIKI page that contains a summar= y of the work to date. Please provide feedback in the EDK II mailing lists= . The WIKI pages will be updated with input from the entire EDK II communi= ty. https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgi= thub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Continuous-Integ= ration&data=3D02%7C01%7Csean.brogan%40microsoft.com%7C6f67f169a6c746b42= 88608d72cbea7b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63702706968664= 4659&sdata=3DGR9wN6gP3mJlCTopAaQ2rlzhby1nuF%2BwDVsfFIQAZjA%3D&reser= ved=3D0 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. 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. ## Pre-Commit Checks in Phase 1 * Run and pass PatchCheck.py with no errors =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 The following are some additional pre-commit check ideas that could be qui= ckly added once the initial version using PatchCheck.py is fully functional= . Please provide feedback on the ones you like and additional ones you thi= nk may improve the quality of the commits to the edk2 repository. ## 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 ## 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 Best regards, Mike