Add dual-output for compatibility with existing tools

[ascandella]

Many tools currently parse the output of go test, which means we can't just drop this helpful tool into a build pipeline without breaking things.

Of note, there's a proposal in upstream Golang to support a standard "go test" output (golang/go#2981) which would help this and many other tools. However this is just a "proposal" and there's no concrete timeline for implementing.

In the meantime, the output of "go test" is the canonical source-of-truth for test runs, and many tools (including go-junit-report(https://github.com/jstemmer/go-junit-report) which I use and contribute to expect the tests runs to output their results in a specific, human-friendly format.

In order to differentiate between output made for humans (which richgo does a great job at doing) and output for machines (which go test currently does, although it's currently both for-machine and for-human, and it isn't very great for humans), I'd like to augment richgo to support outputting both: a human-friendly mode, and a machine-friendly mode.

In the short term, the machine-friendly mode will simply be the input we get from running "go test" unmunged. In the future, it will probably be go test -json or whatever the upstream proposal lands on, which will make everybody's job easier.

The primary changes proposed are to implement two flags (and optionally environment variables):

• the output path to send the human-friendly version to (default: os.Stdout)
• the output path to send the machine-friendly version to (currently ioutil.Discard)

note that rather than hard-coding paths for defaults, will need to do some portability things to make sure we don't hardcode this as /dev/stdout and instead use the more portable os.Stdout and ioutil.Discard istead of /dev/null -- none of this will be difficult but writing it down here so I don't forget it.

Then somebody could run this tool using linux FIFOS (totally untested):

tmpdir=$(mkdtemp -d)
outfifo="${tmpdir}/MYFIFO
mkfifo a=rw "${outfifo}"
go-junit-report < ${outfifo} > junit.xml
richgo test --machine-friendly-output "${outfifo}"

And on their console they would have the default, nice, colorized output on os.Stdout, but go-junit-report would be parsing the "machine-friendly" version.

References #3

[ascandella]

On second thought, this may be entirely unnecessary. I think I could use an appropriately-placed tee to split off the output before invoking richgo, which would allow go-junit-report to see the untouched version while sending richgo's output to stdout. Will do some more investigating.

[kyoh86]

I'm going to use Rich-Go with an alias go=richgo, so I don't want to prepare flags only for this app.

How about a following plan instead?

• Create a new sub-command, richgo testfilter.
• testfilter reads text lines from Stdin, decorates them (as go test output) and write out them.

Then you can use it like this:

# (with process substitution)
go test ./... | tee >(richgo testfilter) | go-junit-report`

# (with FIFO)
tmpdir=$(mkdtemp -d)
outfifo="${tmpdir}/MYFIFO
mkfifo a=rw "${outfifo}"
go-junit-report < ${outfifo} > junit.xml
go test ./... | tee ${outfifo} | richgo testfilter

[ascandella]

Sounds good, and much simpler, I like it :)

[jspiro]

Why not just fix richgo ./... | tee /dev/tty | ... outputting plain ascii and not colored ascii? That seems to be the only problem here.

[ascandella]

It's not just ascii versus colorized. The formatting/indentation/content changes as well, causing issues with tools that make assumptions about any of the above.

…

On Thu, Feb 2, 2017 at 5:49 PM Jono Spiro ***@***.***> wrote: Why not just fix richgo ./... | tee /dev/tty | ... outputting plain ascii and not colored ascii? That seems to be the only problem here. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAF7P0LY-HecubtUpA-8NwM6ioCrqypCks5rYnVFgaJpZM4LqVTd> .