Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: binaries built with test -c do not support -json option #31051

Closed
ijc opened this issue Mar 26, 2019 · 8 comments
Closed

cmd/go: binaries built with test -c do not support -json option #31051

ijc opened this issue Mar 26, 2019 · 8 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@ijc
Copy link

ijc commented Mar 26, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.1 linux/amd64

Does this issue reproduce with the latest release?

I believe 1.12.1 is latest, so yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
/go # go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build705366494=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I am building a test binary using go test -c (with the intention of running the actual test on another host, which has no Go toolchain installed) and I would like to use it with gotestsum (primarily for the --junitfile support to integrate with Jenkins).

However the binaries built this way do not support the -json option required by gotestsum (nor does it support -test.json).

go test --json ./ produces json output while:

$ go test -o foo -c ./
$ ./foo -json
flag provided but not defined: -json
$ ./foo -test.json
flag provided but not defined: -test.json

I'm aware that I can pipe the output of my test binary to go tool test2json but this is inconvenient since the target host lacks Go. I'm going to experiment with working around this by using TestMain to inject something like the code which backs the -json option on go test (https://github.com/golang/go/blob/master/src/cmd/go/internal/test/test.go#L1045...L1049), but it would be great if this just worked.

What did you expect to see?

Support for the -json option in my test binary built with go test -s

What did you see instead?

No support for -json in that binary.

@ijc
Copy link
Author

ijc commented Mar 26, 2019

I'm going to experiment with working around this by ...

I fell at the first hurdle, because test2json is in an internal package...

@agnivade
Copy link
Contributor

test2json is just another binary which lives in $GOROOT/pkg/tool/linux_amd64. So you can just copy foo and test2json in the target host.

@ijc
Copy link
Author

ijc commented Mar 26, 2019

Thanks, but the other host is actually (sometimes) running a different OS (i.e. the build is sometimes a cross-build, sorry, I should have mentioned that!) so it's sadly not as simple as just a copy for me.

@agnivade agnivade changed the title Binaries built with go test -c do not support -json option cmd/go: binaries built with test -c do not support -json option Mar 26, 2019
@agnivade agnivade added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 26, 2019
@agnivade agnivade added this to the Unplanned milestone Mar 26, 2019
@agnivade
Copy link
Contributor

@bcmills @rsc

@ianlancetaylor
Copy link
Contributor

I believe this is in effect a dup of #22996.

@agnivade
Copy link
Contributor

Agree. @ijc - please have a look at @rsc's comment on the issue. The solution is to do a cross-platform build of test2json. I will close this as it was rejected before. Please feel free to reopen if you think otherwise.

@ijc
Copy link
Author

ijc commented Mar 27, 2019

Thanks and sorry for not finding the previous issue (I did search, I promise).

I understand the issues from #22996, it's not ideal but I think I can lash something together, thanks!

ijc added a commit to ijc/docker-app that referenced this issue Apr 1, 2019
As well as gotestsum we now also need to build `test2json` because test
binaries build with `go test -c` do not support the `-test` option. That option
just wraps the test run in the `test2json` code which translates from the
standard output syntax to json. (See golang/go#31051
for more info). This uses `cmd/test2json` the source of which is part of the go
distribution and is therefore available in the base images.

Once we have them then we "simply" chain them together, `gotestsum` takes a
`--raw-command` for which we pass `test2json`. In turn `test2json` takes a
command which it will wrap and we pass the actual e2e test binary.

Since running `test2json` manually gives us the opportunity to set the package
name (with `-p`) we give it a distinct name rather than munging the output
after the fact like we do with the unit tests.

Since the only references to these tools are in `Jenkinsfile.*` we don't need
to worry about making them available for non-containerised runs.

Signed-off-by: Ian Campbell <ijc@docker.com>
ijc added a commit to ijc/docker-app that referenced this issue Apr 1, 2019
As well as gotestsum we now also need to build `test2json` because test
binaries build with `go test -c` do not support the `-test` option. That option
just wraps the test run in the `test2json` code which translates from the
standard output syntax to json. (See golang/go#31051
for more info). This uses `cmd/test2json` the source of which is part of the go
distribution and is therefore available in the base images.

Once we have them then we "simply" chain them together, `gotestsum` takes a
`--raw-command` for which we pass `test2json`. In turn `test2json` takes a
command which it will wrap and we pass the actual e2e test binary.

Since running `test2json` manually gives us the opportunity to set the package
name (with `-p`) we give it a distinct name rather than munging the output
after the fact like we do with the unit tests.

Since the only references to these tools are in `Jenkinsfile.*` we don't need
to worry about making them available for non-containerised runs.

Signed-off-by: Ian Campbell <ijc@docker.com>
ijc added a commit to ijc/docker-app that referenced this issue Apr 2, 2019
As well as gotestsum we now also need to build `test2json` because test
binaries build with `go test -c` do not support the `-test` option. That option
just wraps the test run in the `test2json` code which translates from the
standard output syntax to json. (See golang/go#31051
for more info). This uses `cmd/test2json` the source of which is part of the go
distribution and is therefore available in the base images.

Once we have them then we "simply" chain them together, `gotestsum` takes a
`--raw-command` for which we pass `test2json`. In turn `test2json` takes a
command which it will wrap and we pass the actual e2e test binary.

Since running `test2json` manually gives us the opportunity to set the package
name (with `-p`) we give it a distinct name rather than munging the output
after the fact like we do with the unit tests.

Since the only references to these tools are in `Jenkinsfile.*` we don't need
to worry about making them available for non-containerised runs.

Signed-off-by: Ian Campbell <ijc@docker.com>
ijc added a commit to ijc/docker-app that referenced this issue Apr 2, 2019
As well as gotestsum we now also need to build `test2json` because test
binaries build with `go test -c` do not support the `-test` option. That option
just wraps the test run in the `test2json` code which translates from the
standard output syntax to json. (See golang/go#31051
for more info). This uses `cmd/test2json` the source of which is part of the go
distribution and is therefore available in the base images.

Once we have them then we "simply" chain them together, `gotestsum` takes a
`--raw-command` for which we pass `test2json`. In turn `test2json` takes a
command which it will wrap and we pass the actual e2e test binary.

Running `test2json` manually gives us the opportunity to set the package name
(with `-p`) we give it a distinct name rather than munging the output after the
fact like we do with the unit tests.

Since the only references to these tools are in `Jenkinsfile.*` we don't need
to worry about making them available for non-containerised runs.

`test2json` requires verbose output, so add `-test.v` in one case.

Signed-off-by: Ian Campbell <ijc@docker.com>
ijc added a commit to ijc/docker-app that referenced this issue Apr 5, 2019
As well as gotestsum we now also need to build `test2json` because test
binaries build with `go test -c` do not support the `-test` option. That option
just wraps the test run in the `test2json` code which translates from the
standard output syntax to json. (See golang/go#31051
for more info). This uses `cmd/test2json` the source of which is part of the go
distribution and is therefore available in the base images.

Once we have them then we "simply" chain them together, `gotestsum` takes a
`--raw-command` for which we pass `test2json`. In turn `test2json` takes a
command which it will wrap and we pass the actual e2e test binary.

Running `test2json` manually gives us the opportunity to set the package name
(with `-p`) we give it a distinct name rather than munging the output after the
fact like we do with the unit tests.

Since the only references to these tools are in `Jenkinsfile.*` we don't need
to worry about making them available for non-containerised runs.

`test2json` requires verbose output, so add `-test.v` in one case.

Signed-off-by: Ian Campbell <ijc@docker.com>
@tiny-dancer
Copy link

For future diggers: gotestyourself/gotestsum#77

@golang golang locked and limited conversation to collaborators Dec 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants