Skip to content

EDK II Continuous Integration

Michael Kinney edited this page Sep 16, 2019 · 3 revisions

EDK II Continuous Integration Proposal

Phase 1 (edk2 repository only)

  • Remove write access to edk2 repo
  • EDK II Maintainers use GitHub Pull Request instead of push
  • Only accept PR from EDK II Maintainers. Reject all other PRs.
  • Run basic Pre-commit checks
  • If all Pre-commit checks pass, then auto commit changes
  • If any Pre-commit check fails, then notify submitter
  • Limit pre-commit check execution time to 10 minutes
  • Provide on-demand builds to EDK II Maintainers

Proposed Pre-Commit Checks in Phase 1

  • PatchCheck.py

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

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
Clone this wiki locally
You can’t perform that action at this time.