[edk2-devel] [RFC] EDK II Continuous Integration Phase 1

Michael D Kinney

Hi Michael,

SCTs are in scope. It is only deciding when they get run
and how much pre-commit execution time developers are
willing to wait for a pass/fail result.

The on-demand testing feature is one place we can add extra
testing to help improve the quality of commits. The
Daily and Weekly scoped tests are another option.


-----Original Message-----
From: Michael Zimmermann <sigmaepsilon92@...>
Sent: Thursday, August 29, 2019 1:40 PM
To: devel@edk2.groups.io; Kinney, Michael D
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?


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


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

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


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
Only EDK II Administrators will continue to have
access, and that should only be used to handle
* 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
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
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
* 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

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

Best regards,