The LAVA support scripts are prepared by the Deploy Action Reference action
and the same scripts will be used for all test definitions until another
deploy block is encountered.

-test:failure_retry:3

Definitions are used for POSIX compliant operating
systems on the DUT. The deployed system is expected to support a POSIX
shell environment (/bin/ash, /bin/dash or /bin/bash are the
most common) so that LAVA can execute the LAVA Test Shell Helper
scripts.

Interactive are used for non-POSIX compliant shell like
bootloader (u-boot for instance) shells.

Monitors are used for devices which have no POSIX
shell and start the test immediately, for example IoT boards.

Currently, there is no support for executing arbitrary commands on DUTs
which cannot offer a full POSIX environment. This is being investigated
for a future release.

A simple test definition present in the same file as the job submission,
instead of from a separate file or VCS repository. This allows tests to be run
based on a single file. When combined with file:// URLs to the deploy
parameters, this allows tests to run without needing external access. See
Inline test definition example.

(optional): Pass parameters to the Lava Test Shell Definition. The format is a
YAML dictionary - the key is the name of the variable to be made available to
the test shell, the value is the value of that variable.

When a single test definition is to be used across multiple deployment types
(e.g. Debian and OpenEmbedded), it may become necessary to only perform certain
actions within that definition in specific jobs. The skip_install support
has been migrated from V1 for compatibility. Other methods of optimising test
definitions for specific deployments may be implemented in V2 later.

LAVA collects results from internal operations as well as from the submitted
test definitions, these form the lava test suite results. The full set of
results for a job are available at:

results/1234

LAVA records when a submitted test definition starts execution on the test
device. If the number of test definitions which started is not the same as the
number of test definitions submitted (allowing for the lava test suite
results), a warning will be displayed on this page.

This results in the date and mount test cases being included into a
first_set TestSet, independent of other test cases. The TestSet is
concluded with the lava-test-setstop command, meaning that the uname
test case has no test set, providing a structure like:

if the command is None (“command:” in yaml), the test shell will
wait for the prompts and messages without sending anything to the device.

Note

the interactive shell is expecting the prompt to be already matched
before it starts. If this is not the case, then wait for the prompt by
adding a Nonecommand.

A u-boot interactive test might look like:

-name:networkprompts:["=>","/#"]script:-name:dhcpcommand:dhcpsuccesses:-message:"DHCPclientboundtoaddress"failures:-message:"TIMEOUT"exception:InfrastructureErrorerror:"dhcpfailed"-name:setenvcommand:"setenvserverip{SERVER_IP}"-name:wait for the promptcommand:

A script is a list of commands to send:

command: the command to type in the shell

name: if present, log the result of this command under the given name

failures and successes: if present, check the logs for the given patterns

successes should be a list of dictionaries with only one key:

message: the string (or regexp) to match

Note

if LAVA matches one of the prompt and successes is defined, an
error will be recorded. If successes is not defined, then matching a prompt
will generate a passing result.

failures should be a list of dictionaries with:

message: the string (or regexp) to match

exception: If the message indicates a fatal problem, an exception can be raised:

test_case_id: 1 - Measure time to switch from ISR back to interrupted thread |
| switching time is

Caution

Notice how the regular expression has not closed the match
at the end of the “line” but has continued on to the first
non-matching character. The test case name then concatenates all
whitespace and invalid characters to a single underscore.

The test_case_id will be formed from the match of the expression \d+*-[^-]+ followed by a single space - but only if the rest of the
expression matches as well.

The measurement will be taken from the match of the expression \d+
preceded by a single space and followed by the exact string tcs=``whichitselfmustbefollowedbyanumberofdigits,thenasinglespaceandfinallythe**exact**string``nsec - but only if the rest
of the expression also matches.