computer-readable output when run in a CI job

[4c4d]

I'd really like to use pre-commit for running in a CI job, and output a json blob (or other serialized primitive format). I think that pre-commit is great for being used as a runner for a large set of code quality tests.
I'm already looking into doing the legwork on this, but I wanted to get your opinions on this.

So far, the feature list I'm implementing/"requiring" is:

• --json-output=filepath flag - there's no sane way to head off all of the prints (edit: based on a misreading), so this would probably have to dump to a tempfile somewhere.
• replace the return value of ints with an intermediate retval interface between hooks and pre-commit main - with backcompat, of course. That way, I can encapsulate all text outputs in a list[string] and pass them back to the caller.
• update existing hooks with an intermediate print() replacement, and optional argument to use the intermediate retval.
• Some interesting pre-commit hooks that I need (and will contribute back, if possible).

I'm posting this before I start the bulk of my work, to make sure I'm not stepping on any toes. At the least, I can fork and maybe bring it back in? Please tear this request up.

Btw, I've already started using pre-commit for our needs in a prototype capacity, and I'm really happy with it.

[asottile]

So one thing that's started walking in this direction is log_file added in #530

I don't really want pre-commit to have any more than a subprocess interface with hooks, but the rest of it sounds feasible.

I think a --machine-output f.json option seems fine, but I don't really want to change the interface with hooks to enable that. I think it could produce something like this today though which should be pretty consumable:

{
    "//": "overall result of the run",
    "result": "1",
    "hook_outputs": [
        {
            "repo": "...",
            "hook": "...",
            "hook_output": "whatever got printed",
            "hook_modified_files": ["list", "of", "modified", "files", "if", "applicable"],
            "hook_return_code": 1
         },
         {"//": "etc..."}
    ]
}

[4c4d]

That's great. I'm using a slightly older version than 530 (will update, of course).

For the intermediate, I was thinking of returning a json blob (which has its own set of challenges). Anyways, I'm going to close this and re-evaluate, since it needs some re-thinking.