You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/index.md
+9-6Lines changed: 9 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3728,22 +3728,25 @@ The resulting JSON file encodes an array of `types.Report`. Each entry in that
3728
3728
3729
3729
When possible, we recommend building tooling on top of Ginkgo's JSON format and using Ginkgo's `types` package directly to access the suite and spec reports. The structs in the package include several helper functions to interpret the report.
3730
3730
3731
-
Ginkgo also supports generating JUnit reports with
3731
+
Ginkgo also supports generating output in additional formats, however Ginkgo specs carry much more metadata than can easily be mapped onto different output reports formats, so information may be lost and/or a bit harder to decode than using Ginkgo's native JSON format.
3732
3732
3733
3733
```bash
3734
+
# JUnit report
3734
3735
ginkgo --junit-report=report.xml
3736
+
# Teamcity report
3737
+
ginkgo --teamcity-report=report.teamcity
3738
+
# Go json report (same format as go test -json)
3739
+
ginkgo --gojson-report=report.go.json
3735
3740
```
3736
3741
3737
-
The JUnit report is compatible with the JUnit specification, however Ginkgo specs carry much more metadata than can be easily mapped onto the JUnit spec so some information is lost and/or a bit harder to decode than using Ginkgo's native JSON format. Nonetheless, Ginkgo does its best to populate as much of the JUnit report as possible. This includes adding additional metadata using [labels](#spec-labels) - in particular if you provide a label of the form `Label("owner:XYZ")`, the generating JUnit spec will set the `Owner` attribute to `XYZ`.
3742
+
Ginkgo does it's best to populate relevant fields and attributes across different report formats. This includes adding additional metadata using [labels](#spec-labels), in particular if you provide a label of the form `Label("owner:XYZ")`, the generated JUnit report will set the `Owner` attribute to `XYZ`.
3738
3743
3739
-
Ginkgo also supports Teamcity reports with `ginkgo --teamcity-report=report.teamcity` though, again, the Teamcity spec makes it difficult to capture all the spec metadata.
3740
-
3741
-
All the machine-readable reports include the full `-vv` version of the timeline for all specs. This allows you to run Ginkgo in CI with the normal verbosity setting but still get all the detailed information in the machine-readable format.
3744
+
All the machine-readable reports include the full `-vv` version of the timeline for all specs. This allows you to run Ginkgo in CI with the normal verbosity setting but still get all the detailed information in the machine-readable format.
3742
3745
3743
3746
Of course, you can generate multiple formats simultaneously by passing in multiple flags:
By default, when any of these command-line report flags are provided Ginkgo will generate a single report file, per format, at the passed-in file name. If Ginkgo is running multiple suites (e.g. `ginkgo -r --json-report=report.json`) then _all_ the suite reports will be encoded in the single report file.
0 commit comments