The scripts available in the MultiNode API are not installed for test jobs which are not part of a MultiNode group, so the job will simply fail that test as a command not found.
Other calls which may require communication with other devices may need to be removed from your YAML. This can be extended to retain a set of singlenode YAML files in which new wrapper scripts and new builds are tested.
The Job Definition of one job within a MultiNode group may be a good starting point for creating a singlenode equivalent.
By viewing the complete log, the complete processing of the wrapper script becomes obvious.
#!/bin/sh
set -e
set -x
Pipes, redirects and nested sub shells will not work reliably when put directly into the YAML. Use a wrapper script (with set -x).
#!/bin/sh
set -e
set -x
ifconfig|grep "inet addr"|grep -v "127.0.0.1"|cut -d: -f2|cut -d' ' -f1
Un-nested sub-shells do work:
- lava-test-case multinode-send-network --shell lava-send network hostname=$(hostname) fqdn=$(hostname -f)
A lava-wait must be preceded by a lava-send from at least one other device in the group or the waiting device will timeout
This can be a particular problem if you remove test definitions from the JSON or edit a YAML file without checking other uses of the same file.
If the YAML uses a custom result parser, configure one of your YAML files to output the entire test result output to stdout so that you can reliably capture a representative block of output. Test your proposed result parser against the block using your favourite language.
Comment out the parser from the YAML if there are particular problems, just to see what the default LAVA parsers can provide.
Always check whether the test result came back as failed due to some cause other than the test definition itself. Particularly with MultiNode, a test result can fail due to some problem on a different board within the group.