Any LAVA lab with a publicly available API can
be added to kernelci.org. Or, if you have a private instance of KernelCI, you
can set it up locally too. The KernelCI core tool kci_test
can be used to generate test job definitions and submit them. Then the
kernelci-backend can receive
callback notification HTTP requests directly from LAVA and add the test results
to the database.
A distributed LAVA lab is composed of a main server with a web frontend, and a number of dispatchers which have a direct connection to the devices running tests. For KernelCI development purposes, typically a self-contained LAVA lab can be set up with a server and a single dispatcher with at least one QEMU device instance.
LAVA can be installed natively using Debian packages as per the LAVA documentation. Another convenient way to do this is using the KernelCI LAVA Docker containers.
Once you have a LAVA lab up and running, follow these steps to start running
kernelci.org
tests:
kernel-ci
user as per the LAVA
documentationkernel-ci
user. It will be used for submitting jobs using kci_test
,
either manually or automatically via Jenkins.kernel-ci
user with
the description set to kernel-ci-bisection-webhook
for automated
bisection via Jenkins.runtime-configs.yaml
.test-configs.yaml
if your lab has new device types not already covered by kernelci.org.kernel-ci
user using
kernel-ci-callback
and kernel-ci-callback-staging
respectively as their
descriptions.Your lab will then start being used on staging.kernelci.org to verify it’s all working as expected. Jobs will be scheduled automatically every 8h, and the results will start appearing on the web dashboard and in email reports. Then it will normally get enabled in production kernelci.org to run tests for all the trees and test suites enabled for your lab (or everything by default).