├── .mergify └── config.yml └── README /.mergify/config.yml: -------------------------------------------------------------------------------- 1 | ## @file 2 | # Mergify YML file that automatically merges a GitHub pull request against 3 | # edk2-ci if all of the GitHub branch protections have passed. It also 4 | # contains rules to: 5 | # * auto close branches that are not from an EDK II Maintainer 6 | # * post a comment on pull requests that have merge conflicts. 7 | # * post a comment on pull requests that have PatchCheck.py errors. 8 | # 9 | # Configuration Notes: 10 | # * Update the 'base=edk2-ci' statements with the name of the branch to merge 11 | # pull requests. 12 | # 13 | # * Update the 'status-failure' statement with the name of the name of the Azure 14 | # Pipelines Build that performs the EDK II Maintainer check. 15 | # 16 | # * This file must be checked into the 'default' branch of a repo. Copies 17 | # of this file on other branches of a repo are ignored by Mergify. 18 | # 19 | # Copyright (c) 2019, Intel Corporation. All rights reserved.
20 | # SPDX-License-Identifier: BSD-2-Clause-Patent 21 | # 22 | # https://github.com/apps/mergify 23 | # https://doc.mergify.io/ 24 | # 25 | ## 26 | 27 | pull_request_rules: 28 | 29 | - name: Automatically merge a PR when all required checks pass and 'push' label is present 30 | conditions: 31 | - base=edk2-ci 32 | - label=push 33 | - author=@tianocore/edk-ii-maintainers 34 | - status-success=tianocore.PatchCheck 35 | - status-success=Ubuntu GCC5 PR 36 | - status-success=Windows VS2019 PR 37 | actions: 38 | merge: 39 | strict: true 40 | method: rebase 41 | 42 | - name: Automatically close a PR when all required checks pass and 'push' label is not present 43 | conditions: 44 | - base=edk2-ci 45 | - -label=push 46 | - -closed 47 | - status-success=tianocore.PatchCheck 48 | - status-success=Ubuntu GCC5 PR 49 | - status-success=Windows VS2019 PR 50 | - status-success=Ubuntu GCC5 PR (FINISHED) 51 | - status-success=Windows VS2019 PR (FINISHED) 52 | actions: 53 | close: 54 | message: All checks passed. Auto close personal build. 55 | 56 | - name: Post a comment on a PR that can not be merged due to a merge conflict 57 | conditions: 58 | - base=edk2-ci 59 | - conflict 60 | actions: 61 | comment: 62 | message: PR can not be merged due to conflict. Please rebase and resubmit 63 | 64 | - name: Automatically close a PR that fails the EDK II Maintainers membership check and 'push' label is present 65 | conditions: 66 | - base=edk2-ci 67 | - label=push 68 | - -author=@tianocore/edk-ii-maintainers 69 | actions: 70 | close: 71 | message: PR submitter is not a member of the Tianocore EDK II Maintainers team 72 | 73 | - name: Post a comment on a PR if PatchCheck fails 74 | conditions: 75 | - base=edk2-ci 76 | - status-failure=tianocore.PatchCheck 77 | actions: 78 | comment: 79 | message: PR can not be merged due to a PatchCheck failure. Please resolve and resubmit 80 | 81 | - name: Post a comment on a PR if Ubuntu GCC5 fails 82 | conditions: 83 | - base=edk2-ci 84 | - status-failure=Ubuntu GCC5 PR 85 | - status-success=Ubuntu GCC5 PR (FAILED) 86 | actions: 87 | comment: 88 | message: PR can not be merged due to an Ubuntu GCC5 failure. Please resolve and resubmit 89 | 90 | - name: Post a comment on a PR if Windows VS2019 fails 91 | conditions: 92 | - base=edk2-ci 93 | - status-failure=Windows VS2019 PR 94 | - status-success=Windows VS2019 PR (FAILED) 95 | actions: 96 | comment: 97 | message: PR can not be merged due to a Windows VS2019 failure. Please resolve and resubmit 98 | -------------------------------------------------------------------------------- /README: -------------------------------------------------------------------------------- 1 | This repository is used by EDK II as a staging location for new 2 | features that are not yet ready for inclusion in EDK II. 3 | 4 | Introduction 5 | ================= 6 | Need place on tianocore.org where new features that are not ready for product 7 | integration can be checked in for evaluation by the EDK II community prior to 8 | adding to the edk2 trunk. This serves several purposes: 9 | 10 | * Encourage source code to be shared earlier in the development process 11 | * Allow source code to be shared that does not yet meet all edk2 required quality criteria 12 | * Allow source code to be shared so the EDK II community can help finish and validate new features 13 | * Provide a location to hold new features until they are deemed ready for product integration 14 | * Provide a location to hold new features until there is a natural point in edk2 release cycle to fully validate the new feature. 15 | * Not intended to be used for bug fixes. 16 | * Not intended to be used for small, simple, or low risk features. 17 | 18 | Process for creating, using, and maintaining staging efforts 19 | ======== 20 | [Step 1 is already completed, it is here for documentation purposes; proceed to 2)] 21 | 1) Create a new repo called edk2-staging 22 | a) edk2-staging is a fork of edk2 23 | b) edk2-staging/master tracks edk2/master 24 | 25 | 2) edk2-staging discussions can use the existing edk2-devel mailing list for design/patch/test. 26 | Use the following style for discussion of a specific feature branch in edk2-staging repo. 27 | 28 | [staging/branch]: Subject 29 | 30 | 3) All commits to edk2-staging must follow same edk2 rules 31 | 32 | 4) Process to add a new feature to edk2-staging 33 | a) Maintainer sends patch email to edk2-devel mailing list announcing the creation of a new 34 | feature branch in edk2-staging with Readme.MD. Readme.MD is in root of feature branch 35 | with summary, owners, timeline, links to related materials. 36 | b) Maintainer creates feature branch in edk2-staging 37 | c) Maintainer is responsible for making sure feature is frequently synced to edk2/master 38 | 39 | NOTE: Feature branch may initially use a stable edk2 tag. As feature stabilizes, 40 | syncs to edk2/master can begin. 41 | 42 | 5) Process to update sources in feature branch 43 | a) Commit message subject format: 44 | 45 | [staging/branch PATCH]: Package/Module: Subject 46 | 47 | b) Directly commit changes to feature branch or if community review is desired, 48 | then use edk2-devel review process. 49 | 50 | NOTE: win32 binaries are not automatically generated if a feature branch includes BaseTools source changes. 51 | 52 | 6) Process to promote an edk2-staging branch to edk2 trunk 53 | a) Use edk2 patch review/commit process on edk2-devel mailing list. 54 | The specific git actions used to add the feature to edk2 is at the discretion 55 | of the maintainer(s) doing the merge. A merge commit must always contain the final 56 | 'Reviewed-by:' tags. 57 | b) Remove feature branch from edk2-staging and archive at https://github.com/tianocore/edk2-archive. 58 | 59 | 7) Process to remove an edk2-staging branch 60 | a) Stewards may periodically review of feature branches in edk2-staging (once a quarter?) 61 | b) If no activity for extended period of time and feature is no longer deemed a candidate 62 | for edk2 then stewards send email to edk2-devel to request deletion of feature branch. 63 | c) If no objections from EDK II community, then feature branch is deleted and archived at 64 | https://github.com/tianocore/edk2-archive. 65 | 66 | 8) How to evaluate a feature in edk2-staging 67 | a) Clone edk2 68 | b) Create local branch with optional platform packages 69 | c) Build platform in local branch and verify it is stable 70 | d) Clone edk2-staging/[branch name] 71 | e) Create local branch with optional platform packages 72 | f) Build platform in local branch and evaluate new feature 73 | --------------------------------------------------------------------------------