This guide aims to enable users to be able to
Ensure you have read through the introduction on Writing a LAVA test shell definition.
Pay particular attention to sections on:
lava-tool
is already installed on your test system and a
suitable authentication token has been added.To install lava-tool
, see lava-tool.
To authenticate lava-tool
, see Authentication Tokens.
To find out more about submitting tests written by someone else, see Submitting your first job.
To find out more about viewing job details, see Job Submission.
Use the LAVA scheduler to view the device types and devices available in your LAVA instance. The main scheduler status page shows data for each device type as well as the currently active jobs. Also check the Devices pages:
For a MultiNode job, you may need to check more than one device type.
LAVA looks at the device status when working out if a particular device is available for a new job:
Typically, the easiest thing to do here is to start with an image which is already in use in LAVA. You can find one of these images by checking the device type in LAVA and viewing some of the jobs for devices of this type from the table on that page. e.g. for QEMU devices on validation.linaro.org:
There are three important sets of actions that will normally be run for a LAVA test:
actions:
- deploy:
timeout:
minutes: 5
to: tmpfs
images:
rootfs:
image_arg: -drive format=raw,file={rootfs}
url: https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
compression: gz
os: debian
A device tag marks a specified device as having specific hardware capabilities which other devices of the same device type may not. To test these capabilities, a test job can specify a list of tags which the device must support. If no devices exist which match all of the required tags, the job submission will fail. If devices support a wider range of tags than required in the test job (or the test job requires no tags), any of those devices can be used for the test job.
Note
Test jobs which use device tag support can only be submitted to instances which have those tags defined and assigned to the requested boards. In your LAVA instance, check the device information to see what tags are used.
When writing a normal single-node test job, the desired tags should be
listed as a top level list of strings in the job definition, i.e. at
the same level as job_name
, timeouts
, metadata
and
device_type
:
# Your first LAVA JOB definition for an x86_64 QEMU
device_type: qemu
job_name: QEMU pipeline, first job
tags:
- tap_device
- virtual_io
timeouts:
job:
minutes: 15
action:
minutes: 5
priority: medium
visibility: public
# context allows specific values to be overridden or included
context:
# tell the qemu template which architecture is being tested
# the template uses that to ensure that qemu-system-x86_64 is executed.
arch: amd64
metadata:
# please change these fields when modifying this job for your own tests.
docs-source: first-job
docs-filename: qemu-pipeline-first-job.yaml
For MultiNode test jobs, the tags are defined as part of the MultiNode protocol block:
protocols:
lava-multinode:
roles:
client:
device_type: qemu
context:
arch: amd64
count: 1
# In this example, only one role in the group uses tags
tags:
- tap_device
- virtual_io
server:
device_type: qemu
context:
arch: amd64
count: 1
timeout:
seconds: 60
Device tags are only relevant during scheduling of the test job and have no meaning to the dispatcher once the job is running.
If an MD5 or SHA256 checksum is provided alongside the URL of the file to be
used in a test job, the downloaded content will be checked against the provided
checksum. The test job will fail as Incomplete
if the checksum fails to
match.
Avoid using URLs which include shortcuts like latest
when providing
the checksum. Specify the full URL to ensure consistency between tests.
See also
The lava_test_shell
action provides a way to employ a black-box
approach to testing on the target device. Its format is:
- test:
failure_retry: 3
name: kvm-basic-singlenode
timeout:
minutes: 5
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: smoke-tests-basic
description: "Basic system test command for Linaro Ubuntu images"
run:
steps:
- printenv
from: inline
name: env-dut-inline
path: inline/env-dut.yaml
- repository: git://git.linaro.org/lava-team/lava-functional-tests.git
from: git
path: lava-test-shell/smoke-tests-basic.yaml
name: smoke-tests
- repository: https://git.linaro.org/lava-team/lava-functional-tests.git
from: git
path: lava-test-shell/single-node/singlenode03.yaml
name: singlenode-advanced
The definitions
list here may contain multiple test definition
URLs. These will all be run sequentially in one run on the test
device, and it will not be rebooted between the definitions.
See also
See also
lava_test_shell
developer documentation