On 21/03/2016 15:31, Neil Williams wrote:

JSON submissions do not support this. Test actions are more typically described inside a LAVA Test Shell Definition where there is metadata per definition and a name for each lava-test-case. lava-command is designed for situations where a script needs to run on the dispatcher to get the device into a suitable mode. As such, there is little benefit in having more than one sequential block, the expectation is that the command list would contain all commands required at that point. lava_command is not a test action, it is a dispatcher action, so does not support the same type of metadata.

I get your point, but I'm not 100% clear why we still need two different actions/classes, since both lava-command and lava-test-shell will only allow running commands on the target (or a node more generally), unless adding host-side hooks. Does this limitation remain with the pipeline mode ?

M.

On 21 March 2016 at 14:18, Marc Titinger mtitinger@baylibre.com wrote:

...

Hi Neil and all,

how do I add per-action comments or meta data so that I can parse them from the result bundle:

the following for instance will pass the schema validation, but the result bundle will degenerate into keeping only the last "comment" metadata entry, while I'd like a per-action metadata entry.

 {
     "command": "lava_command_run",
     "metadata":
     {
         "comment": "comment1"
     },
     "parameters":
     {
         "commands": [
             "uname -a"
         ]
     }
 },
 {
     "command": "lava_command_run",
     "metadata":
     {
         "comment": "comment2"
     },
     "parameters":
     {
         "commands": [
             "ls -al"
         ]
     }
 },

The result bundle will contain the same metadata for each lava-command:

         "attributes": {
             "comment": "comment2",    <=== same value
             "image.type": "kernel-ci",

.... snip ...

             "logging_level": "DEBUG",
             "device.tree": "omap4-panda-es.dtb"
         },
         "test_id": "lava-command"

IOW, how do I assign a brief description to an action ?

Thanks and regards, Marc.

---

Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users

On 21/03/2016 16:34, Neil Williams wrote:

On 21 March 2016 at 15:16, Marc Titinger mtitinger@baylibre.com wrote:

...

I get your point, but I'm not 100% clear why we still need two different actions/classes, since both lava-command and lava-test-shell will only allow running commands on the target (or a node more generally), unless adding host-side hooks. Does this limitation remain with the pipeline mode ?

There are a number of inconsistencies and workarounds in V1, hence the work on V2.

There is no equivalent of lava_command in V2. Job metadata in V2 will be job-specific, retaining metadata within test shell definitions, specific to that test shell definition, including inline definitions.

sounds good.

I'm not really sure what you're trying to achieve with lava_command,

I'm running a list of test commands on the target while recording power measurements using an external device controlled by hooks run by the dispatcher. I could do the same by hooking lava-test-shell instead I reckon, but it seemed to involve some overhead in the target setup compared to lava-command, that I did not need.

but if you are running commands on the device, a test definition is the way to do that and to have definition-specific metadata.

got it, thanks.