Structured Output

[jezzsantos]

Today we support the structured output of all commands (--output-structured).

The original idea was to provide the output as a data structure (like structured logging) to be more easily readable by client tooling to avoid binding to exact output messages and thus forced to scrape the required from them. (The data is of interest, not really the human-readable content).

At the moment, only the CLI output (stdout) is structured, but not the CLI errors (stderr) where exceptions are captured. The CLI output is structured in JSON.

The automate-plugin-rider project will now be calling the CLI (from Java) and it will require a structured output for both success and failure commands (in both stderr and stdout).

Perhaps in the success case we see something like this in stdout:

{
 "Info" : [
    "acontextualmessage1",
    "acontextualmessage2"
  ],
  "Output" : [{
    "Message" : "a message template with some value {AName1} and with some data {AName2}",
    "Values" : {
      "AName1": "avalue",
      "AName2": {
        "AKey1" : "value1",
        "AKey2" : "value2"
      },
    }
  }]
}

Perhaps in the failure case we see something like this in stderr:

{
 "Info" : [
    "acontextualmessage1",
    "acontextualmessage2"
  ],
  "Error": {
    "Message" : "...an error message..."
  },
  "Output" : []
}

Where you can tell if there is an error, by checking for the existence of the error element in stderr.

[jezzsantos]

We are not quite there yet.

I think we need to be sure that non-string outputs (like JSON) are output correctly first.