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
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
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.
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.
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
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
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
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:
