GitLab

This is posted based on https://linaro.atlassian.net/browse/TFC-442 . As a quick recap, it's about a CI job submitting a LAVA job producing 200MB log, then trying to download it. This download appears to guaranteedly fail (https://ci.trustedfirmware.org/job/tf-a-builder/2058583/consoleFull):

00:40:04.330 + resilient_cmd sh -c 'lavacli jobs logs --raw 1591316 > /home/buildslave/workspace/tf-a-builder/lava-raw.log'
00:40:04.331 + set +x
00:45:41.078 ERROR: Command 'sh -c lavacli jobs logs --raw 1591316 > /home/buildslave/workspace/tf-a-builder/lava-raw.log' failed 10 times in row

Trying to reproduce it manually (lavacli 1.9), I see exactly the same behavior, it 100% fails:

$ lavacli jobs logs --raw 1591316 > log
Unknown error: while parsing a block collection
  in "<unicode string>", line 1, column 1
did not find expected '-' indicator
  in "<unicode string>", line 2176, column 2

)() I have no idea why the error message like above doesn't show in the CI log (I verified that it's output to stderr and not stdout). But the error message itself appears to be from YAML parsing, which somehow doesn't correspond to the --raw flag. I'd expect that with --raw, any output received from LAVA API would be directly printed, without any attempts at parsing. Likewise, watching the memory usage of the command run locally (which spikes up to 1GB), again it seems that the log is for some reason is accumulated in the memory, whereas for --raw behavior, I would expect it to be "streamed" from LAVA to stdout (chunk by chunk, without any accumulation).

All in all, I suspect that such behavior (attempt at parsing) might be the reason the command 100% fails, and with such a confusing error message. It's pretty clear that 200MB log is just too big, but this ticket is what behavior lavacli has in such cases, and whether we can improve it.