Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now that we have GitHub Actions build, we can use them to perform runtime validation, at build time, of the UEFI executables we produce through QEMU, as well as make the build artefacts available for download.
To accomplish that, we first need to fix the MinGW builds, that were producing broken executables (hence the reason why you want to have runtime tests at build) as well as fix the output of the apps we are going to use for testing, that were producing unwanted extra lines. This is accomplished with the first 2 patches.
The next patch then enables the generation of the GitHub Actions artifacts, which we will need for testing, and the last patch adds the actual tests, where you will see, on GitHub Actions output, that an extra task for the tests is now run after a successful build.
The testing is designed to be flexible and easy to modify (to add more tests as needed), as the whole test sequence, expected output, and buildup/teardown is defined in the
test_list.txt
file. This is based on what I already use in uefi-md5sum.Basically, a test entry in that file starts with a
#
line that defines the display name for the test, and bash commands prefixed by>
or<
, that are used for buildup and teardown respectively, and, without any prefix, the expected text output of the test. Some shell variables ($UEFI_DIR
and$UEFI_ARCH
) can also be used in the bash commands.Since we run UEFI applications and not UEFI bootloaders, most of the buildup is designed to create a
startup.nsh
Shell script that will be automatically executed by the Shell before we shutdown the QEMU UEFI firmware withreset -s
(since we need to exit QEMU so that we don't error on a timeout, which is also detected).This text file can then be converted to a series of bash scripts through
gen_tests.sh
, which are then run through therun_tests.sh
script, which then produces an output similar to:This is the output you will see, for each arch, in the
Run tests
step of thetests
action.At this stage, this testing obviously relies on elements that need to be sourced from third-parties, namely the AVMF/OVMF firmwares, a copy of which (along with their provenance) can be found at https://github.com/pbatard/EfiFs/tree/gh-pages/AAVMF and https://github.com/pbatard/EfiFs/tree/gh-pages/OVMF which is the content behind the https://efi.akeo.ie URL and that have been sourced from Debian packages, as well as the UEFI Shell, for which I also provide executables, built directly from stable EDK2 builds through GitHub Actions, at https://github.com/pbatard/UEFI-Shell.
For now, only
x64
,ia32
,aa64
andarm
are being tested, but I'll see if I can work on addingriscv64
at a later date.Hopefully, this will help detect regressions as they arise.