Skip to content

EDK II Continuous Integration

Jump to bottom Edit New page
Michael D Kinney edited this page Nov 26, 2019 · 1 revision

EDK II Continuous Integration

Summary of pre-commit and post-commit Continuous Integration services that improve the quality of commits made to EDK II repositories. The sections below list the Continuous Integration services that are active and plans for future enhancements and extensions to these services.

Phase 1 (edk2 repository only) - Activated November 11, 2019

  1. Use a combination of GitHub, Azure Pipelines, Mergify, and edk2-pytool features.
  2. Enable the following pre-commit checks
  3. TianoCore EDK II Maintainers Team permissions reduced from 'Write" to "Triage"
  4. EDK II Maintainers must use GitHub pull request with 'push' label to request a branch to be strict rebase merged into edk2/master. If all checks pass, then the patches in the pull request are automatically added to edk2/master. If any checks fails, then email notifications are sent and details of the failure are available through Azure Pipelines test results.
  5. Personal builds available to all EDK II developers using a GitHub pull request without the 'push' label set. If all checks pass, then a notification email is sent and the pull request is closed. If any checks fails, then email notifications are sent and the details of the failure are available through Azure Pipelines test results.
  6. GitHub References
  7. HUB Command line Utility to perform GitHub operations
  8. Azure Pipelines References
  9. Mergify References

EDK II Continuous Integration Administration

Proposed Pre-Commit Checks in Phase 2

  • Verify Reviewed-by and Acked-by tags are present with correct maintainers
  • Verify no non-ASCII characters in modified files
  • Verify no binary files in set of modified files

Proposed Pre-Commit Checks in Phase 3

  • Run ECC on modified files
  • Verify modified modules/libs build
  • Run available Host Based tests against modified modules/libs

Post Commit Checks

  • Build all modules/libs/platforms that consume modified content

Daily Builds

  • Build critical packages
  • Build critical platforms
  • Verify that Doxygen Documentation can be generated

Weekly Builds

  • Build all packages
  • Build all platforms
  • Publish Doxygen Documentation to a web site

Release Builds

  • Same as weekly builds
  • Full regression testing
  • Publishes binary files to release pages

Possible Continuous Integration Actions

  • PatchCheck.py
  • Verify Reviewed-by and Acked-by tags are maintainers
  • Verify no non-ASCII characters in modified source files
  • Verify no binary files in set of modified files
  • Verify Package Dependency rules in modified files
  • Verify modified modules/libs build
  • Run Host Based tests against modified modules/libs
  • cppcheck
  • ECC (EFI Code Checker)
    • Difficult to address all warnings/issues/false positives reported
    • May need to maintain an exception list
  • Static Analysis against modified modules/libs
    • CLANG static analysis
    • Coverity: https://scan.coverity.com/
    • Difficult to address all warnings/issues/false positives reported
    • May need to maintain an exception list
  • pyflakes (for python sources)
  • pylama (for python sources)
  • Generate Package Documentation (Doxygen based)
  • Build all Packages/Platforms for all supported CPU architectures (IA32, X64, ARM, AARCH64, EBC), all supported tool chains (VS2015, VS2017, GCC5, XCODE5), and all supported build targets (DEBUG, RELEASE, NOOPT). Needs further discussion on required coverage.
  • Boot platforms to UEFI Shell
  • Run UEFI SCTs and collect results for platforms
  • Linaro LAVA CI
  • Boot platforms to OS(s)
  • Integration/Regression tests that require full OS boots
  • Build binary releases of components (e.g. UEFI Shell, OVMF)

Possible Platform Testing Actions

  • OVMF
    • IA32 DXE boot tests
    • X64 DXE boot tests
    • ArmVirt QEMU boot tests
    • S3 enabled tests
    • SMM_REQUIRE enabled tests
    • Boot using both KVM and QEMU environments
    • HTTPS Boot Tests
    • UEFI Secure Boot Sanity Testing
      • Enroll UEFI Secure Boot Keys
      • UEFI Secure Boot testing of "unsigned" images
      • UEFI Secure Boot testing of "signed but not recognized" images
      • UEFI Secure Boot testing of "signed and accepted" images
      • UEFI Secure Boot testing of "signed but blacklisted" images
    • Project that offers a python script that automates communicating with the UEFI shell over the emulated serial port. Used in downstream package builds, for packaging a pre-enrolled variable store template file.

Future Enhancements

  • Support non-maintainer GitHub Pull Requests that are submitted after code review is complete. Maintainers must still be part of the review/approval process before the PR is run through pre-commit tests auto committed.

Evaluations and Supporting Background Materials

pip install --upgrade -r requirements.txt
stuart_setup -c .\CISettings.py
stuart_update -c .\CISettings.py
stuart_ci_build -c .\CISettings.py --Tool_Chain VS2017

Draft for Review

Clone this wiki locally