See Handling repeats.
Selected Actions within the dispatcher support repeating an individual action (along with any internal pipelines created by that action) - these are determined within the codebase.
Blocks of actions can also be repeated to allow a boot and test cycle to be repeated. Only Boot Action Reference and Test Action Reference are supported inside repeat blocks.
Selected actions (RetryAction
) within a pipeline (as determined by the
Strategy) support repetition of all actions below that point. There will only
be one RetryAction
per top level action in each pipeline. e.g. a top level
Boot Action Reference action for U-Boot would support repeating the attempt to
boot the device but not the actions which substitute values into the U-Boot
commands as these do not change between boots (only between deployments).
Any action which supports failure_retry
can support repeat
but not in
the same job. (failure_retry
is a conditional repeat if the action fails,
repeat
is an unconditional repeat).
Individual actions can be retried a specified number of times if the a
JobError Exception or InfrastructureError Exception is raised
during the run
step by this action or any action within the internal
pipeline of this action.
Specify the number of retries which are to be attempted if a failure is
detected using the failure_retry
parameter.
- deploy:
failure_retry: 3
RetryActions will only repeat if a JobError Exception or InfrastructureError Exception exception is raised in any action inside the internal pipeline of that action. This allows for multiple actions in any one deployment to be RetryActions without repeating unnecessary tasks. e.g. download is a RetryAction to allow for intermittent internet issues with third party downloads.
Individual actions can be repeated unconditionally using the repeat
parameter. This behaves similarly to Retry on failure except that the
action is repeated whether or not a failure was detected. This allows a device
to be booted repeatedly or a test definition to be re-run repeatedly. This
repetition takes the form:
- actions:
- deploy:
# deploy parameters
- boot:
method: qemu
media: tmpfs
repeat: 3
prompts:
- 'linaro-test'
- 'root@debian:~#'
- test:
# test parameters
Resulting in:
[deploy], [boot, boot, boot], [test]
To repeat a specific boot and a specific test definition as one block ([boot,
test], [boot, test], [boot, test] ...
), nest the relevant Boot Action Reference
and Test Action Reference actions in a repeat block.
actions:
- deploy:
timeout:
minutes: 20
to: tmpfs
image: https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
os: debian
root_partition: 1
- repeat:
count: 6
actions:
- boot:
method: qemu
media: tmpfs
prompts:
- 'linaro-test'
- 'root@debian:~#'
- test:
failure_retry: 3
name: kvm-smoke-test
timeout:
minutes: 5
definitions:
This provides a shorthand which will get expanded by the parser into a deployment and (in this case) 6 identical blocks of boot and test.