This is an old revision of the document!
The first goal in CIP testing was the creation of the B@D (Board at Desk) virtual machine. This allows developers to easily run automated testing on a local Beaglebone Black or Renesas RZ/G1M iwg20m platform.
The next goal for CIP is to centralise testing, so that developers can run tests without having local access to a platform. This will become more and more useful for CIP as the list of reference platforms grows. It also means that tests can be triggered and run automatically 24/7.
The block diagram below provides an overview of CIP's centralised test infrastructure.
Explanations for each block are below.
This schedules submitted test jobs to run on available hardware targets.
CIP have set up their own instance of LAVA (Linaro Automated Validation Architecture). LAVA is a continuous integration system for deploying operating systems onto physical and virtual hardware for running tests. See the LAVA website for more details.
CIP are using a version of LAVA maintained by the KernelCI project which containerises support in a Docker image.
A LAVA worker (or lab) manages target (virtual/physical hardware) control. There can be one or many different LAVA workers.
Currently CIP has one LAVA worker (lab-cip-renesas) based in the Renesas UK office. Targets attached to the worker can be viewed on the master website.
CIP encourage as many LAVA workers to be set up as possible and have provided a guide on how to do this.
A target is the physical (or virtual) platform connected to a LAVA worker.
The aim is to have every CIP reference platform connected to at least one worker. Ideally there should be more than one of each platform so that more hardware configurations can be tested.
KernelCI / Mailing list
AWS S3 Bucket
GitLab
GitLab
GitLab
Mailing List / GitLab pull requests
Various
Various