The Linutronix Test Environment (CI) automatically tests changes of the PREEMPT_RT patch on different hardware platforms with a defined test procedure. Following is a description of the defined test procedure and the hardware infrastructure.
The test environment monitors the branches of the two git repositories hosting the PREEMPT_RT patches with the corresponding Linux mainline kernel. A new commit in a single branch triggers a test run for this branch. In a single test run, a defined set of kernel configurations are tested. The test procedure for a kernel configuration goes through up to three phases, depending on the specification:
- Build test: The kernel configuration (with a defined overlay, such as debug overlay) is compiled on a build server with the source of the updated branch. There is no need for an assigned target for every kernel configuration of this phase.
- Boot test: The built kernel and device tree are booted on the specified target. For this, kexec is used. This test is successful only if there is no warning output during boot.
- Cyclictest: After a successful boot, the latency measurement tool cyclictest is used to detect system latency under a defined load. If the latency exceeds a defined threshold, cyclictest aborts and this test phase fails.
The state of the entire test run is a combination of all interim test phase results.
The figure shows the structure of the CI-RT
infrastructure. There is a single control instance, the Jenkins master,
monitoring the branches of the PREEMPT_RT git repository. This instance
starts the three different test phases on the Jenkins slaves. The first
test phase is processed on the Jenkins slave "build server". The second
and third test phases are processed on the test targets, which are also
registered Jenkins slaves. The test targets are located in a test
rack. This rack is similar to those in the well
known OSADL QA farm. For abstract communication with the targets
a tool called r4d (Remote For Dut) is used. In order to use a
generic API, libvirt was adapted to communicate with r4d.
The test results are stored in the database of the web interface. The web interface displays the test results.
For setting up the infrastructure, please visit CI-RT github project.
The standardized elbe based root file systems for the test targets can be downloaded here. The test targets need to fulfil several requirements to be placed into the test rack (see "System Requirements" for more details).