support reading stdout/stderr from streams #415
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pohly
commented
Jun 15, 2024
| @@ -70,6 71,10 @@ func setupFlags(name string) (*pflag.FlagSet, *options) { | |||
| "use different icons, see help for options") | |||
| flags.BoolVar(&opts.rawCommand, "raw-command", false, | |||
| "don't prepend 'go test -json' to the 'go test' command") | |||
| flags.BoolVar(&opts.readStdin, "stdin", false, | |||
| "don't run any command, instead read go test stdout from stdin") | |||
| flags.IntVar(&opts.readStderrFD, "stderr", 0, | |||
There was a problem hiding this comment.
Should this be a named file instead?
Perhaps some elaborate invocation could work without a named pipe. In practice, I think with bash one has to rely on one.
pohly
changed the title
|
I added documentation and unit tests. I also checked that this really works for Kubernetes: kubernetes/kubernetes#125534. |
It can be useful to let the user run the test command(s) itself, for example when complex shell scripts are involved which need to invoke `go test` multiple times. With -stdin, the `go test` stdout is expected on stdin of gotestsum, so it can be used in a pipe. To detect abnormal termination of the test commands, bash with "set -o pipefail" should be used. Beware that such failures are not detected by gotestsum. To also capture stderr with gotestsum, stderr must get redirected like this: mkfifo /tmp/pipe go test ... 2>/tmp/pipe | gotestsum -stdin -stderr 3 3</tmp/pipe
pohly
commented
Jun 16, 2024
|
|
||
| in := `{"Time":"2024-06-16T14:46:00.343974039 02:00","Action":"start","Package":"example.com/test"} | ||
| {"Time":"2024-06-16T14:46:00.378597503 02:00","Action":"run","Package":"example.com/test","Test":"TestSomething"} | ||
| {"Time":"2024-06-16T14:46:00.378798569 02:00","Action":"pass","Package":"example.com/test","Test":"TestSomething","Elapsed":0} |
There was a problem hiding this comment.
The linter is unhappy about the line length.
Is that a hard criteria for code? Any suggestion how to avoid it? Splitting up the line in the middle IMHO would be worse than a long line.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It can be useful to let the user run the test command(s) itself, for example when complex shell scripts are involved which need to invoke
go testmultiple times.With -stdin, the
go teststdout is expected on stdin of gotestsum, so it can be used in a pipe. To detect abnormal termination of the test commands, bash with "set -o pipefail" should be used. Beware that such failures are not detected by gotestsum.To also capture stderr with gotestsum, stderr must get redirected like this:
Fixes: #414