Submitting your first job

A job defines what software should be deployed on the device under test (DUT) and what actions should be performed there. Jobs are defined in YAML files.

Job Definition

Here’s an example minimal job that you should be able to use right away if you have user access to an appropriately-configured LAVA installation.

# Your first LAVA JOB definition for an x86_64 QEMU
device_type: qemu
job_name: QEMU pipeline, first job

    minutes: 15
    minutes: 5
    minutes: 2
priority: medium
visibility: public

# context allows specific values to be overridden or included
  # tell the qemu template which architecture is being tested
  # the template uses that to ensure that qemu-system-x86_64 is executed.
  arch: amd64

  # please change these fields when modifying this job for your own tests.
  docs-source: first-job
  docs-filename: qemu-pipeline-first-job.yaml

- deploy:
      minutes: 5
    to: tmpfs
        image_arg: -drive format=raw,file={rootfs}
        compression: gz
    os: debian

- boot:
      minutes: 2
    method: qemu
    media: tmpfs
    prompts: ["root@debian:"]
      login_prompt: "login:"
      username: root

- test:
      minutes: 5
    - repository:
      from: git
      path: lava-test-shell/smoke-tests-basic.yaml
      name: smoke-tests
    - repository:
      from: git
      path: lava-test-shell/single-node/singlenode03.yaml
      name: singlenode-advanced

Download / view

Job Submission

Jobs may be submitted to LAVA in one of three ways:

  • the command line (using the lava-tool program); or
  • the XML-RPC API
  • the web UI


lava-tool is a general-purpose command line interface for LAVA which can be used directly on the LAVA server machines and also remotely on any computer running a Debian-based distribution. See lava-tool for more information.

See also

To configure a fresh installation of lava-tool to be able to submit test jobs see lava-tool

For now, lava-tool is the easiest option to demonstrate. Once you have copied the above job definition to a file, (for example /tmp/job.yaml), use lava-tool to submit it as a test job in Linaro’s main LAVA lab:

$ lava-tool submit-job https://<username>
submitted as job:


Replace username with your username. Enter the password for the encrypted keyring (if using older versions of lava-tool) - this is the same that was used when adding the authentication token

Once the job is submitted successfully, the job id is returned; this may be used in order to check the status of the job via the web UI. In the above submission the job id returned is 82287. Visit the link provided -<job-id> - in order to see the details of the job run: the test device chosen, the test results, etc. (Older versions of lava-tool only return the job ID number.)


It may take some time before the job actually starts, depending on the number of jobs waiting in the queue for a device of this type. Once the job starts, the status information will automatically update and the logs will appear.

Results are populated live and will start to appear during the operation of the deploy action. The plain log can be downloaded and the definition is available for later reference. If you are the submitter of the job, you can also choose to cancel the job.

Test Definitions

In order to run a test, a test definition is required. A test definition is expressed in YAML format. A minimal test definition would look something like the following:

    name: passfail
    format: "Lava-Test-Shell Test Definition 1.0"
    description: "Pass/Fail test."
    version: 1.0

        - "lava-test-case passtest --result pass"
        - "lava-test-case failtest --result pass"

The first job mentioned above uses a more complex test definition:

The metadata in a test definition is for the maintenance of that test definition and covers details like the maintainer, the kinds of devices which may find this test definition useful and the scope of the test definition. (Scope is arbitrary, often a scope of functional is used to describe a test which is useful to test that the image is functioning correctly.) The run steps of this definition are:

       - lava-test-case linux-linaro-ubuntu-pwd --shell pwd
       - lava-test-case linux-linaro-ubuntu-uname --shell uname -a
       - lava-test-case linux-linaro-ubuntu-vmstat --shell vmstat
       - lava-test-case linux-linaro-ubuntu-ifconfig --shell ifconfig -a
       - lava-test-case linux-linaro-ubuntu-lscpu --shell lscpu
       - lava-test-case linux-linaro-ubuntu-lsb_release --shell lsb_release -a

This simple test executes a series of commands in the booted image. The exit value of each command is used to determine whether the test case passed or failed. You can try any of these commands on a Ubuntu or Debian system to see what the commands should create as output.

Viewing test results

On the job view page, there is a button to access the Results. Results can also be accessed from the Results Overview in the menu. The results for the first job example could look like:


The results include the test definitions submitted within the job as well as a reserved lava set of results generated during the operation of the test job itself. There is also metadata which is generated by the test job, including details like the URL of the test definitions used and the type of deploy and boot methods involved in the test job.

Downloading test results

LAVA makes the test results available directly from the instance, without needing to go through lava-tool. The results for any test job which the user can view can be downloaded in CSV or YAML format.

For example, the results for test job number 123 are available in CSV format using: The same results for job number 123 are available in YAML format using:

If you know the test definition name, you can also download the results for that specific test definition only in a similar way: for the data in CSV format and for the YAML format.

Test definition names use a prefix to show the sequence within the test job, for each namespace. The list of test definitions within a test job can be retrieved using the Summary:

Some test jobs can be restricted to particular users or groups of users. The results of these test jobs will be restricted in the same way. To download these results, you will need to specify your username and one of your Authentication Tokens when using the REST API. Remember to quote the URL if using it on the command line, to avoid the & character being mis-interpreted by your shell, for example:

$ curl ''

Use the Username as specified in your Profile - this may differ from the username you use if logging in via LDAP.


Take care of your tokens - avoid using personal tokens in scripts and test definitions, or any other files that end up in public git repositories. Wherever supported, use https:// when using a token to avoid it being sent in plain-text.

Chunking test suite results

When jobs have a large number of test results in a particular test suite, it is advisable to use test case chunking, to provide pagination for downloading test cases via the REST API.

Two special query string arguments are supported for allowing users to chunk the test cases when downloading test suite results.

  • Limit - determines how many results to read in this chunk
  • offset - the number of results already received

Limit and offset are supported only for test suite exports (both csv and yaml). Example:

$ curl ''

$ curl ''

To retrieve the full count of testcases in a single test suite (useful for pagination), you can use the testcase-count REST API method, like so:

$ curl ''


Test cases will be ordered by ID regardless of whether pagination is used or not. This applies to downloading test cases for a particular test suite only.

Web Based Job Submission

Remember to check the YAML syntax of your test job files using the Online YAML parser before submission.

See also

YAML syntax

The Scheduler menu contains a Submit Job action which can be used to submit jobs to any instance using your browser. You need to be logged in and have permission to submit jobs to that instance. The web submission form for a localhost installation would be http://localhost/scheduler/jobsubmit.

To submit jobs to the Linaro lab in Cambridge, visit Paste your YAML file into the window and click the “Submit” button. An example job submission screen is shown below,



If a link to a test job YAML file is pasted on the above screen, the YAML file will be fetched and displayed in the text box for submission. Make sure that the link is to the raw content of the YAML file, not HTML.

Once the job is successfully submitted, the job details are displayed. (If a list of jobs was created, the first job in the list will be displayed.)


XML-RPC Job Submission

lava-tool is a wrapper around the XML-RPC API with helpers for personal usage. The XML-RPC API itself supports a variety of queries and operations which can assist in creating a frontend to LAVA which can automate the submission of test jobs.

Many languages have XML-RPC support, the API help page on each LAVA instance provides a python example script, with and without using tokens. Job submission requires using an authentication token and should use https wherever possible to protect the token.

See also

For help using the XML-RPC API to submit jobs, see the sections on lava-tool and the Available methods link from the API menu of the LAVA instance. For example: http://localhost/api/help.