Dispatcher Action Reference¶
Job submissions for the pipeline dispatcher use YAML and test writers can create a pipeline of actions based on three basic types. Parameters in the YAML and in the device configuration are used to select the relevant Strategy for the job and this determines which actions are added to the pipeline.
In addition, the job has some general parameters, including a job name and Timeout Reference.
Deploy Actions¶
Boot Actions¶
- Boot Action Reference
- auto_login
- prompts
- connection
- connection-namespace
- commands
- failure_message
- ignore_kernel_messages
- method
Test Actions¶
Other test job elements¶
reboot_to_fastboot¶
This is specific to test jobs that operate on:
android operating system
DUT requested by the job is fastboot based
DUT requested by the job does not use a PDU for power control
It is used to specify whether the DUT should reboot to fastboot mode at the end of the test job. The default value is true i.e., the DUT will be rebooted to fastboot mode. This support is useful in the following use cases:
The DUT does not charge in fastboot mode, in which case the user wants the DUT to stay booted.
A dedicated DUT to a specific team, which does not want to deploy new images frequently to the DUT, instead want to run some tests directly assuming the DUT is booted.
Some disadvantages using this support are as follows:
Some test images that gets deployed to the DUT may have issues in retaining battery charge due to poor configuration. In such cases the DUT runs out of charge and becomes unusable for the next job, which should be handled by manual intervention, thus hindering automation.
Android test images which are not built with USB debugging enabled, cannot be communicated with
adb, thus hindering automation. Since,adbis used to reboot the DUT to bootloader mode, when the DUT is booted, in the absence of a PDU for power control.When a DUT is shared between teams there is a possibility that a test image is flashed on the previous test job, which may not be the suitable test image for the next job by a different team’s member, which assumes the device is booted and tries to run tests.
It is the responsibility of the test writer who assumes the DUT is booted already, to check if the previous test job left the DUT in a state that is suitable for running the current test - LAVA does not take care of cleaning up the test environment in this case.
In order to keep the DUT booted with android operating system at the end of the test job run use the following in test job definition:
reboot_to_fastboot: false
Further Examples¶
The number and range of test jobs is constantly increasing. The LAVA software team develop functional tests in a dedicated git repository: https://git.linaro.org/lava-team/refactoring.git Tests can then migrate into standard tests and examples in the documentation. Even so, not all dispatcher actions have a matching example.
See also