Additional fields in inspec reports

[alexpop]

This is an enhancement request to add additional fields to the inspec reports in order to ease data collection and parsing.

For example, when running:

inspec exec profile.tar.gz --format json

the output has the following format:

{
  "version": "0.24.0",
  "summary": {},
  "profiles": {},
  "other_checks": []
}

Adding additional fields like:

  "source": "inspec",
  "type": "exec"

would make reports ingestion code cleaner and safer. Cheers!

[arlimus]

@alexpop : We just had an offline discussion around type with @chris-rock and both really liked it (it's simple, clear, no confusion, and used by other APIs as well).

[arlimus]

Actually, all of these fields look quite optional in general. i.e. when considering how any command could output JSON, we have to start considering providing all of them with version, application and type information. eg should inspec detect carry this info? how about when we just run a resource to retrieve its content, would that require enriching of JSON as well?

I believe this information is useful in some instances. version is such an example. InSpec's JSON which generates a report falls into this category, imho, as report JSONs may have changing formats over time. Ditto then for exec's --format json outputter, as it builds on reports.

So how about type? The field becomes relevant in an event-based API model which sends different types of events, i.e. we need a type.

tl;dr:

• I don't see a reason to add a source // application field just now. These can be added by enriching engines. Most API's I have looked into (Slack, Github, Docker, ...) don't add this field.
• In some cases, a version field is added. I initially inherited this practice from RSpec's formatter. I'm missing a good story around this field...
• As for the type field, imho it should only go to eventing engines, imho. There is great references to this behavior from other API's I checked (github , docker, slack ... )

[arlimus]

On enriching engines: We had a discussion offline and talked about adding more data, that users can provide via inspec, eg metadata that a user can insert. The use-case is solid, ie we want the reports to be enriched with information about inspec and the context in which scans were run (eg via scanner, via chef client, ...). This imho is a separate component that provides multiple means of mangling data/info streams and prepare them for storage. There are systems out there that can do this beautifully. It'd be great, imho, to keep InSpec's core small.

[arlimus]

Let's reopen this with a use-case again.