Skip to content

Feature: Add gitlab CI integration

Glenn Washburn (CI) requested to merge feature/gitlab-testing into master

These changes add gitlab CI integration to build and test supported targets. This is implemented in .gitlab-ci.yml and scripts in the .ci directory. The gitlab config is designed with reasonable defaults and some flexibility in manually starting pipelines with non-default behavior. Currently, all supported targets except mipsel-loongson are built, but only about 6 targets are running the functional make check tests due to a variety of issues (let's resolve them!). The testing allows for ignoring failure in certain tests, ignoring a subset of failed tests in grub_func_test, and ignoring grub-shell tests which fail due to qemu running longer than its configured timeout. There are some comments in the config file noting why certain targets having testing disabled and/or some test failures are ignored by default.

NOTE: I've used basically the same build procedure as the travis CI config, however, I don't believe that actually tests the mipsel architecture and just duplicates the build for the mips architecture. Hopefully, someone with mips experience can help with this and getting mipsel-loongson building.

By default, test failures due to grub-shell timeouts are ignored. This mostly affects the arm-efi target which seems to run extremely slow (depending on runner). These timeouts are not real test failures because the test never completes, so we do not know if the test would have failed or not, and thus a failure would be inaccurate and likely wrong. These ignored tests are aggregated and output in the final job of the pipeline for all tested targets for convenience.

This CI config file is also configured to kick-off on merge requests. The way this project is configured, those merge request pipelines will be run in the account of the merge requester. This is generally good in that it does not count toward this project's resource allotment. However, this means that a malicious merge requester could make it look like all tests passed, when they in fact did not. I don't consider this a serious issue.

The image used as a base to run these pipelines is the official Ubuntu Xenial docker image. This was chosen to show support for building and testing on older systems. Ubuntu Focal can be used with a few less work-arounds in the CI config.

The gcc cross compiler tool chain version that is used by default is the latest 10.1.0, however, other versions can easily be specified in manual builds.

By default each architecture has its own ccache which is shared with all builds of that architecture. This speeds up the building, however, since most of the time is spent in the testing, its not a huge gain.

There are several environment variables that can be modified to turn on various kinds of tracing to aid in debugging and by default TEST_VERBOSITY is set to 2, which turns on shell tracing of grub-shell and tests that are shell scripts. If TEST_VERBOSITY is set, files generated by grub-shell will be kept in a directory for each test and bundled in test-data.tar.xz for each target.

There are changes to various tests and testing infrastructure which are required for the running of the functional tests or increase the functionality of the testing. These changes should be fairly transparent to other testing environments (with the exception of the renaming of UEFI firmware images for arm-efi and arm64-efi).

Edited by Glenn Washburn (CI)

Merge request reports