Re: [RFC] EDK II Continuous Integration Phase 1


Michael D Kinney
 

Responses below.

Mike

-----Original Message-----
From: Gao, Liming <liming.gao@intel.com>
Sent: Friday, August 30, 2019 1:44 AM
To: rfc@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@intel.com>; devel@edk2.groups.io
Subject: RE: [RFC] EDK II Continuous Integration Phase
1

Mike:
I add my comments.

-----Original Message-----
From: rfc@edk2.groups.io [mailto:rfc@edk2.groups.io]
On Behalf Of
Michael D Kinney
Sent: Friday, August 30, 2019 4:23 AM
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 <rebecca@bsdio.com> Jenkins evaluation
* Laszlo Ersek <lersek@redhat.com> GitLab evaluation
* Philippe Mathieu-Daudé <philmd@redhat.com> GitLab
evaluation
* Sean Brogan <sean.brogan@microsoft.com> Azure
Pipelines and HBFA
* Bret Barkelew <Bret.Barkelew@microsoft.com> Azure
Pipelines and HBFA
* Jiewen Yao <jiewen.yao@intel.com> HBFA

The following link is a link to an EDK II WIKI page
that contains a
summary 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 community.


https://github.com/tianocore/tianocore.github.io/wiki/
EDK-II-Continuous
-
Integration

Proposal
========
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.

Will the maintainer manually provide pull request after
the patch passes the review?
Can the script scan the mail list and auto trig pull
request once the patch gets Reviewed-by or Acked-by
from Package maintainers?
The maintainer will do this step manually. After the
required Reviewed-by and Acked-by responses have been
received, the commit messages in the patch series must
be updated to include the Reviewed-by and Acked-by tags.
I do not see an easy way to automate the editing of the
commit messages and guarantee it is always correct.


* 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
The maintainer manually trig pre-commit check or auto
trig pre-commit?
By default, pre-commit should be auto trigged based on
pull request.
Automatically triggered.

I would be good to provide an on-demand service for maintainers
to run the exact same pre-commit checks on a branch to see
if there are issues that need to be resolved.


* 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.

Will Pre-commit check fail send the mail to the patch
submitter?
Yes.

The patch submitter need update the patch and go
through review process again.
Potentially. If it is a very simple merge conflict with
no functional impacts, then the maintainer should be able
to resolve and resubmit without additional code review.

If there are functional changes to resolve merge conflict,
then another review cycle would be required.


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

=====================================================

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.

## 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
Now, Edk2 has few binary files, like logo.bmp.
I see one BZ to request logo bmp update.
(BZ
https://bugzilla.tianocore.org/show_bug.cgi?id=2050)
So, we need the exception way for it.

* 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
I request boot test on Emulator and Ovmf in the daily
and weekly scope.
Daily can cover boot to Shell.
Weekly can cover more boot functionality.

Thanks
Liming
Best regards,

Mike






Join rfc@edk2.groups.io to automatically receive all group messages.