From: "Sean" <sean.brogan@microsoft.com>
To: Zhang, Shenglei <shenglei.zhang@intel.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg
Date: Fri, 27 Mar 2020 19:29:12 -0700 [thread overview]
Message-ID: <15209.1585362552937064110@groups.io> (raw)
In-Reply-To: <20200326070418.25824-1-shenglei.zhang@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]
There are two parts of this I think should be discussed.
1. Core-Ci for emulator, ovmf, armvirt packages.
a. I think there is some value here for those package maintainers. The core ci does spell checks, char encoding checks, lib class declaration, etc. Those seem valuable to help keep the package clean.
B. The core ci works on an assumption that the DSC builds every module within the package and for that I think you would want to create new DSC file in those packages that included every module in the package and used NULL libs to resolve as many dependencies as possible. That DSC would be only for Core CI.
2. Platform Ci for emulator, ovmf, armvirt packages.
a. I think this is what we want long term. It would compile the platform and ideally do boot testing and checks.
b. Platform Ci should scale out to all sorts of platforms (open and closed src) that want to register for CI and are willing to keep their platform current.
c. Should be a signal into the PR process. I don't think it should block by policy, but reviewers should use the results to evaluate the impact of the PR.
d. I have setup a branch here with Platform CI.
1. Code changes to enable pytool to build of OVMF and EmulatorPkg. https://github.com/spbrogan/edk2/tree/ci-for-ovmf
2. 4 pipelines here: https://dev.azure.com/tianocore/edk2-ci-play/_build?treeState=XEVtdWxhdG9yUGtnJFxPVk1G&view=folders
3. OVMF GCC5: 8 builds. see the matrix here https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4915&view=results and https://github.com/spbrogan/edk2/blob/ci-for-ovmf/.azurepipelines/platforms/Ovmf/Ubuntu-GCC5.yml#L22. This worked without issue.
4. OVMF VS2019: Same 8 builds. Results here: https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4916&view=results and matrix file here https://github.com/spbrogan/edk2/blob/ci-for-ovmf/.azurepipelines/platforms/Ovmf/Windows-VS2019.yml#L22. The full build fails 2 of the "flavors". See https://bugzilla.tianocore.org/show_bug.cgi?id=2636
5. EmulatorPkg GCC: 2 builds. https://dev.azure.com/tianocore/edk2-ci-play/_build?definitionId=39&_a=summary IA32 fails so it currently only builds X64
6. EmulatorPkg VS2019: 2 builds https://dev.azure.com/tianocore/edk2-ci-play/_build?definitionId=40&_a=summary IA32 fails so it currently only builds X64.
Feedback wanted. Happy to add more if there is some agreement that you like this direction.
Also if you have ideas how to run the images and then exit from the shell with a status so we can tell success/failure that would be great.
Thanks
Sean
[-- Attachment #2: Type: text/html, Size: 4191 bytes --]
next prev parent reply other threads:[~2020-03-28 2:29 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 7:04 [PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg Zhang, Shenglei
2020-03-26 7:11 ` [edk2-devel] " Rebecca Cran
2020-03-26 7:50 ` [EXTERNAL] " Bret Barkelew
2020-03-26 8:43 ` Ard Biesheuvel
2020-03-26 8:45 ` Zhang, Shenglei
2020-03-27 14:36 ` Laszlo Ersek
2020-03-27 14:39 ` Laszlo Ersek
2020-03-26 23:26 ` [EXTERNAL] " Bret Barkelew
2020-03-27 0:00 ` Michael D Kinney
2020-03-27 0:14 ` Bret Barkelew
2020-03-27 1:59 ` Michael D Kinney
2020-03-27 2:04 ` Liming Gao
2020-03-27 2:50 ` Sean
2020-03-28 2:29 ` Sean [this message]
2020-03-28 2:38 ` [edk2-devel] " Rebecca Cran
2020-03-28 2:48 ` Sean
2020-03-28 19:29 ` Sean
2020-03-28 20:28 ` Ard Biesheuvel
2020-03-28 21:47 ` Sean
2020-03-29 8:51 ` Ard Biesheuvel
2020-03-29 23:16 ` Sean
2020-03-30 1:44 ` Andrew Fish
2020-03-30 6:07 ` Ard Biesheuvel
2020-03-30 9:31 ` Sean
2020-03-30 9:35 ` Ard Biesheuvel
2020-03-30 17:00 ` Sean
2020-03-30 17:04 ` Ard Biesheuvel
2020-03-30 17:11 ` Sean
2020-03-30 17:44 ` Ard Biesheuvel
2020-03-30 19:07 ` Sean
2020-03-30 19:51 ` Ard Biesheuvel
2020-03-30 20:56 ` Laszlo Ersek
2020-03-30 21:03 ` Sean
2020-03-30 21:13 ` Rebecca Cran
2020-04-05 6:39 ` Sean
2020-04-06 10:11 ` Ard Biesheuvel
2020-04-07 13:21 ` Laszlo Ersek
2020-03-30 21:22 ` Ard Biesheuvel
2020-03-31 12:13 ` Laszlo Ersek
2020-03-30 21:11 ` Laszlo Ersek
2020-03-30 21:29 ` Michael D Kinney
2020-03-30 21:42 ` Sean
2020-03-30 21:46 ` Ard Biesheuvel
2020-03-31 6:31 ` Sean
2020-03-31 6:40 ` Ard Biesheuvel
2020-03-31 16:26 ` Sean
2020-03-31 16:32 ` Ard Biesheuvel
2020-03-30 22:45 ` Rebecca Cran
2020-03-30 22:58 ` Michael D Kinney
2020-03-31 12:27 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15209.1585362552937064110@groups.io \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox