public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Subject: [RFC] EDK II Continuous Integration Phase 1
Date: Thu, 29 Aug 2019 20:22:41 +0000	[thread overview]
Message-ID: <E92EE9817A31E24EB0585FDF735412F5B9DA6404@ORSMSX113.amr.corp.intel.com> (raw)

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






             reply	other threads:[~2019-08-29 20:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29 20:22 Michael D Kinney [this message]
2019-08-29 20:39 ` [edk2-devel] [RFC] EDK II Continuous Integration Phase 1 Michael Zimmermann
2019-08-29 21:08   ` Michael D Kinney
2019-08-30  2:21 ` Sean
2019-08-30 13:11   ` [edk2-devel] " Laszlo Ersek
2019-09-13 21:00     ` Sean
2019-09-16 11:06       ` Laszlo Ersek
2019-09-19 21:45   ` Michael D Kinney
2019-09-19 21:55   ` Michael D Kinney
2019-09-20 21:29     ` Sean
2019-09-23 17:44       ` Michael D Kinney
2019-09-24 14:05         ` Liming Gao
2019-08-30  8:43 ` Liming Gao
2019-08-30 12:58   ` [edk2-devel] " Laszlo Ersek
2019-09-03  3:39     ` [edk2-rfc] " Ni, Ray
2019-09-03 13:19       ` Laszlo Ersek
2019-09-03 16:41         ` Ni, Ray
2019-09-03 16:55           ` Laszlo Ersek
2019-09-03 17:09             ` Sean
2019-09-03 17:45               ` Laszlo Ersek
2019-09-19 21:13                 ` Michael D Kinney
2019-09-04 23:56           ` rebecca
2019-09-19 17:53   ` Michael D Kinney
2019-08-31 20:31 ` [edk2-rfc] " rebecca
2019-09-17  3:46 ` [edk2-devel] " rebecca

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=E92EE9817A31E24EB0585FDF735412F5B9DA6404@ORSMSX113.amr.corp.intel.com \
    --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