thanks @woodie - i think i see you’ve got two PRs going? Let me know when the dust settles and you’d like me to take a look.

thanks @woodie - i think i see you’ve got two PRs going? Let me know when the dust settles and you’d like me to take a look.

Both PRs are almost identical with slight changes to reporters/default_reporter.go:
• 1669 may feel bolted on with several methods starting with a short cirtuit.if r.conf.FdOutput { return }
• 1670 attempts to integrate with minimal changes and should work better with future refactoring.

I've renamed the PRs. I like the 2nd approach as only so many things can be bolted on without creating a mess.

OK, I like this PR @onsi. I did post a couple questions in the Issue. The dust has settled for me.

Hey @onsi, are we ready to merge this?

hey sorry - i'd missed your earlier reply on the issue.

I think this will work great if the user simply runs ginkgo -fd. but if they run ginkgo -p -fd or ginkgo -randomize-all -fd it will generate interleaved output that won't make sense. I think that's fine (changing the behavior is likely too complex - and doesn't match the use-case), but I think what we'd want is to have Ginkgo emit an error and refuse to run if you mix -fd with -p, -numProcs=N (with N>1), or -randomize-all. Are you up for adding that guard?

Alternatively, if you've tried it with -p and -randomize-all and think the output is fine, lemme know!