-----Original Message-----
From: Michael Zimmermann <sigmaepsilon92@...>
Sent: Thursday, August 29, 2019 1:40 PM
To: devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@...>
Cc: rfc@edk2.groups.io
Subject: Re: [edk2-devel] [RFC] EDK II Continuous
Integration Phase 1

Hi Michael,

would it make sense to run SCT (using UnixHost and/or
qemu) to verify the high level logic or do you think
that would be too much to do for each PR?

Also, do we want to run all these checks for each
commit in the PR to verify that they pass at each point
in the git history?

Thanks
Michael

On Thu, Aug 29, 2019 at 10:22 PM Michael D Kinney
<michael.d.kinney@...> wrote:

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@...> Jenkins evaluation
* Laszlo Ersek <lersek@...> GitLab evaluation
* Philippe Mathieu-Daudé <philmd@...> GitLab

evaluation

* Sean Brogan <sean.brogan@...> Azure

Pipelines and HBFA

* Bret Barkelew <Bret.Barkelew@...> Azure

Pipelines and HBFA

* Jiewen Yao <jiewen.yao@...> 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/E
DK-II-Continuou

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

* 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

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

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