Standard test job for QEMU - Stretch amd64¶

The first standard job to look at is a small step on from the first example job:

# Standard Stretch amd64 JOB definition for QEMU
device_type: qemu
job_name: qemu amd64 standard build, Debian Stretch

timeouts:
  job:
    minutes: 10
  action:
    minutes: 2
  connection:
    minutes: 2
priority: medium
visibility: public

Download / view full job definition

Context¶

Some device types can support multiple types of deployment in the template and the job context variable is used in the test job submission to dictate how the test job is executed. The first example test job included the use of context and the standard test job for QEMU extends this:

context:
  arch: amd64
  # comment out or change to user if the dispatcher does not support bridging.
  netdevice: tap

arch¶

The context variable arch dictates which QEMU binary is used to execute the test job. The value needs to match the architecture of the files which QEMU is expected to execute. In this case, amd64 means that qemu-system-x86_64 will be used to run this test job.

netdevice¶

The context variable netdevice is used by the jinja template to instruct QEMU to use the tap device on the command line. This support expects that the dispatcher has a working network bridge available. (Setting up a network bridge is beyond the scope of this documentation.) The purpose of the tap device is to allow the virtual machine to be visible for external connections like reverse DNS and SSH. If your local instance does not support the tap device, the netdevice option should be commented out so that QEMU can use the default user networking support.

Deploy¶

This is also familiar from the first job. The addition here is that the standard image build exports the SHA256sum of the prepared files to allow the checksum to be passed to LAVA to verify that the download is the correct file:

actions:
# DEPLOY_BLOCK
- deploy:
    timeout:
      minutes: 4
    to: tmpfs
    images:
        rootfs:
          image_arg: -drive format=raw,file={rootfs}
          url: http://example.com/stretch.img.gz
          sha256sum: b5cdb3b9e65fec2d3654a05dcdf507281f408b624535b33375170d1e852b982c
          compression: gz

Boot¶

Here is another small change from the first example job. The standard build also outputs details of the prompts which will be output by the image upon boot. This information is then used in the test job submission:

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

Test¶

The standard QEMU test job for stretch adds an inline test definition as the only change from the example first job:

- test:
    timeout:
      minutes: 5
    definitions:
    - repository:
        metadata:
          format: Lava-Test Test Definition 1.0
          name: smoke-tests-basic
          description: "Basic system test command for Debian images"
        run:
          steps:
          - printenv
      from: inline
      name: env-dut-inline
      path: inline/env-dut.yaml
    - repository: http://git.linaro.org/lava-team/lava-functional-tests.git
      from: git
      path: lava-test-shell/smoke-tests-basic.yaml
      name: smoke-tests
    - repository: http://git.linaro.org/lava-team/lava-functional-tests.git
      from: git
      path: lava-test-shell/single-node/singlenode03.yaml
      name: singlenode-advanced

Next steps¶

Before moving on to the next standard test jobs for non-emulated devices like the beaglebone-black and cubietruck, consider spending some time developing the standard QEMU test job:

Add more commands to the inline test definition
Follow the link from the metadata and use the instructions to rebuild the image.
- Modify the metadata to point at your build information
- Modify the SHA256sum and the URL in the deploy action.
Write a new test definition using version control and make it available publicly, then add that definition to your test job based on this first standard test job.