go-junit-report: Go test output as JUnit XML for your CI system

A pipe between go test and a JUnit consumer

go-junit-report converts the output of go test into a JUnit compatible XML report, suitable for use with applications such as Jenkins. That is the whole purpose, and it exists because most CI systems were built around the JUnit XML convention long before Go had a test runner, so a Go pipeline has to translate. The default behaviour reads verbose go test output from stdin and writes the XML report to stdout, which means it composes as a pipe rather than a wrapper. The typical invocation pipes the test run into the converter and redirects the report into a file:

go test -v 2>&1 ./... | go-junit-report -set-exit-code > report.xml

The -set-exit-code flag is the detail that makes it usable in a script, because it makes the converter exit with 1 when the tests failed, so a pipeline can rely on the exit status of the last command in the pipe.

stderr is where build errors live

The 2>&1 in that command is not decoration. The README explains that Go build and runtime errors are also supported, but that this requires stderr to be redirected to go-junit-report as well. Without it, a package that fails to compile produces output the converter never sees, and the report comes out empty or misleading rather than showing the failure. The same requirement is repeated for the JSON parser, where the README notes that stderr still needs to be redirected in order for build errors to be detected. The v2.0.0 changelog shows the project tightened this area, with entries for distinguishing between build and runtime errors and for test failures, and for handling build errors in packages with the _test suffix while not ignoring build errors that did not belong to a package.

Two parsers, one for plain output and one for JSON

The -parser flag selects how the input is read. The default parser is called gotest and handles the text output of go test -v. The alternative, gojson, handles the structured JSON that go test -json produces:

go test -json 2>&1 | go-junit-report -parser gojson > report.xml

The JSON path is the more precise of the two because the go test JSON stream labels each event, and the v2.1.0 changelog shows the project fixing a case where JSON output was not parsed correctly when go test ran with the -race flag. The plain text parser also had to keep up with Go itself, and one changelog entry adds support for the === NAME lines introduced in Go 1.20. Two further v2.1.0 fixes matter in practice: timestamps in the generated report were made more accurate, and illegal XML characters in the output are now escaped, which is the kind of bug that breaks a CI dashboard rather than a build.

Benchmarks, file input and the flag table

Go benchmark output is supported as well. The README's example runs the benchmarks for the package in the current directory five times and writes the report to a file with the -out flag:

go test -v -bench . -count 5 2>&1 | go-junit-report -out report.xml

The -iocopy flag copies stdin straight to stdout, which is useful when you want to see exactly what was fed to the converter, and it can only be used together with -out:

go-junit-report -in tests.txt -iocopy -out report.xml

The full flag list in the README is short enough to read in one pass. -in and -out set the input and output files, -no-xml-header suppresses the XML declaration, -package-name supplies a fallback when the output has no package name, -p adds key=value properties to the report, and -subtest-mode chooses between ignoring-parent-results and exclude-parents for how parent test results are treated. Running go-junit-report -help prints the same list at runtime.

The parser and the report writer are importable packages

The tool is not restricted to command line use, and this is the part that makes it reusable. The test output parser and the JUnit XML report generator are also published as Go packages, and the README points to them on pkg.go.dev as github.com/jstemmer/go-junit-report/v2/parser/gotest and github.com/jstemmer/go-junit-report/v2/junit. If you want to use the parser or generate your own custom JUnit reports, that is the supported path, and it means you can embed report generation inside a larger tool rather than shelling out. The v2.0.0 release reorganised this area, replacing the older formatter and parser packages with junit and parser/gotest, and it added a Testsuites.WriteXML convenience method in v2.1.0.

Version 2, a module path with a major suffix, and MIT

The repository is not archived and the last push was on 2026-08-19, but the tagged releases are older, with v2.1.0 published on 2023-10-18 after v2.0.0 in July 2022. The module path carries the major version, github.com/jstemmer/go-junit-report/v2, so the install command has to include it, which is also the import path for the packages. The go.mod declares Go 1.13 as the minimum, and the v2.0.0 changelog records that support for parsing pre-Go 1.13 test output was dropped, so a very old toolchain is not a target. The licence is MIT, the repository has a Makefile that builds a Linux, Windows, macOS amd64 and macOS arm64 release artefact with the version, revision and build time stamped into the binary, and pre-built packages for those platforms are published on the releases page, which the README recommends over building from source.

Editorial conclusion

go-junit-report suits a Go project whose CI system understands JUnit XML but not the go test output format, and it suits teams that want to build their own report generator on top of the parser. It does not suit a pipeline that already consumes go test -json directly, since that format is richer and already structured. Before adopting, redirect stderr as well as stdout, because build errors are only detected when stderr reaches the tool, and check the -subtest-mode setting if your suite relies on parent test results.

Frequently asked questions

Official sources

1. Issues
2. jstemmer/go-junit-report on GitHub
3. License: MIT
4. README
5. Releases