2025-03-27 12:59:43 -07:00
# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
# See https://llvm.org/LICENSE.txt for license information.
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
2025-04-10 09:17:25 +00:00
# To run these tests:
# python -m unittest generate_test_report_lib_test.py
2024-11-13 09:19:10 +00:00
import unittest
from io import StringIO
from textwrap import dedent
2025-03-27 12:59:43 -07:00
from junitparser import JUnitXml
import generate_test_report_lib
2024-11-13 09:19:10 +00:00
def junit_from_xml ( xml ) :
return JUnitXml . fromfile ( StringIO ( xml ) )
class TestReports ( unittest . TestCase ) :
def test_title_only ( self ) :
2025-03-27 12:59:43 -07:00
self . assertEqual (
generate_test_report_lib . generate_report ( " Foo " , 0 , [ ] ) , ( " " , " success " )
)
2024-11-13 09:19:10 +00:00
def test_no_tests_in_testsuite ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
2024-11-13 09:19:10 +00:00
" Foo " ,
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
1 ,
2024-11-13 09:19:10 +00:00
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 0.00 " >
< testsuite name = " Empty " tests = " 0 " failures = " 0 " skipped = " 0 " time = " 0.00 " >
< / testsuite >
< / testsuites > """
)
)
] ,
) ,
( " " , None ) ,
)
def test_no_failures ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
2024-11-13 09:19:10 +00:00
" Foo " ,
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
0 ,
2024-11-13 09:19:10 +00:00
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 0.00 " >
< testsuite name = " Passed " tests = " 1 " failures = " 0 " skipped = " 0 " time = " 0.00 " >
< testcase classname = " Bar/test_1 " name = " test_1 " time = " 0.00 " / >
< / testsuite >
< / testsuites > """
)
)
] ,
) ,
(
dedent (
""" \
# Foo
* 1 test passed """
) ,
" success " ,
) ,
)
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
def test_no_failures_build_failed ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
" Foo " ,
1 ,
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 0.00 " >
< testsuite name = " Passed " tests = " 1 " failures = " 0 " skipped = " 0 " time = " 0.00 " >
< testcase classname = " Bar/test_1 " name = " test_1 " time = " 0.00 " / >
< / testsuite >
< / testsuites > """
)
)
] ,
buildkite_info = {
" BUILDKITE_ORGANIZATION_SLUG " : " organization_slug " ,
" BUILDKITE_PIPELINE_SLUG " : " pipeline_slug " ,
" BUILDKITE_BUILD_NUMBER " : " build_number " ,
" BUILDKITE_JOB_ID " : " job_id " ,
} ,
) ,
(
dedent (
""" \
# Foo
* 1 test passed
All tests passed but another part of the build * * failed * * .
[ Download ] ( https : / / buildkite . com / organizations / organization_slug / pipelines / pipeline_slug / builds / build_number / jobs / job_id / download . txt ) the build ' s log file to see the details. " " "
) ,
" error " ,
) ,
)
2024-11-13 09:19:10 +00:00
def test_report_single_file_single_testsuite ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
2024-11-13 09:19:10 +00:00
" Foo " ,
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
1 ,
2024-11-13 09:19:10 +00:00
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 8.89 " >
< testsuite name = " Bar " tests = " 4 " failures = " 2 " skipped = " 1 " time = " 410.63 " >
< testcase classname = " Bar/test_1 " name = " test_1 " time = " 0.02 " / >
< testcase classname = " Bar/test_2 " name = " test_2 " time = " 0.02 " >
< skipped message = " Reason " / >
< / testcase >
< testcase classname = " Bar/test_3 " name = " test_3 " time = " 0.02 " >
< failure > < ! [ CDATA [ Output goes here ] ] > < / failure >
< / testcase >
< testcase classname = " Bar/test_4 " name = " test_4 " time = " 0.02 " >
< failure > < ! [ CDATA [ Other output goes here ] ] > < / failure >
< / testcase >
< / testsuite >
< / testsuites > """
)
)
] ,
) ,
(
dedent (
""" \
# Foo
* 1 test passed
* 1 test skipped
* 2 tests failed
## Failed Tests
2025-04-10 09:17:25 +00:00
( click on a test name to see its output )
2024-11-13 09:19:10 +00:00
### Bar
< details >
< summary > Bar / test_3 / test_3 < / summary >
` ` `
Output goes here
` ` `
< / details >
< details >
< summary > Bar / test_4 / test_4 < / summary >
` ` `
Other output goes here
` ` `
< / details > """
) ,
" error " ,
) ,
)
MULTI_SUITE_OUTPUT = (
dedent (
""" \
# ABC and DEF
* 1 test passed
* 1 test skipped
* 2 tests failed
## Failed Tests
2025-04-10 09:17:25 +00:00
( click on a test name to see its output )
2024-11-13 09:19:10 +00:00
### ABC
< details >
< summary > ABC / test_2 / test_2 < / summary >
` ` `
ABC / test_2 output goes here
` ` `
< / details >
### DEF
< details >
< summary > DEF / test_2 / test_2 < / summary >
` ` `
DEF / test_2 output goes here
` ` `
< / details > """
) ,
" error " ,
)
def test_report_single_file_multiple_testsuites ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
2024-11-13 09:19:10 +00:00
" ABC and DEF " ,
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
1 ,
2024-11-13 09:19:10 +00:00
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 8.89 " >
< testsuite name = " ABC " tests = " 2 " failures = " 1 " skipped = " 0 " time = " 410.63 " >
< testcase classname = " ABC/test_1 " name = " test_1 " time = " 0.02 " / >
< testcase classname = " ABC/test_2 " name = " test_2 " time = " 0.02 " >
< failure > < ! [ CDATA [ ABC / test_2 output goes here ] ] > < / failure >
< / testcase >
< / testsuite >
< testsuite name = " DEF " tests = " 2 " failures = " 1 " skipped = " 1 " time = " 410.63 " >
< testcase classname = " DEF/test_1 " name = " test_1 " time = " 0.02 " >
< skipped message = " reason " / >
< / testcase >
< testcase classname = " DEF/test_2 " name = " test_2 " time = " 0.02 " >
< failure > < ! [ CDATA [ DEF / test_2 output goes here ] ] > < / failure >
< / testcase >
< / testsuite >
< / testsuites > """
)
)
] ,
) ,
self . MULTI_SUITE_OUTPUT ,
)
def test_report_multiple_files_multiple_testsuites ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
2024-11-13 09:19:10 +00:00
" ABC and DEF " ,
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
1 ,
2024-11-13 09:19:10 +00:00
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 8.89 " >
< testsuite name = " ABC " tests = " 2 " failures = " 1 " skipped = " 0 " time = " 410.63 " >
< testcase classname = " ABC/test_1 " name = " test_1 " time = " 0.02 " / >
< testcase classname = " ABC/test_2 " name = " test_2 " time = " 0.02 " >
< failure > < ! [ CDATA [ ABC / test_2 output goes here ] ] > < / failure >
< / testcase >
< / testsuite >
< / testsuites > """
)
) ,
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 8.89 " >
< testsuite name = " DEF " tests = " 2 " failures = " 1 " skipped = " 1 " time = " 410.63 " >
< testcase classname = " DEF/test_1 " name = " test_1 " time = " 0.02 " >
< skipped message = " reason " / >
< / testcase >
< testcase classname = " DEF/test_2 " name = " test_2 " time = " 0.02 " >
< failure > < ! [ CDATA [ DEF / test_2 output goes here ] ] > < / failure >
< / testcase >
< / testsuite >
< / testsuites > """
)
) ,
] ,
) ,
self . MULTI_SUITE_OUTPUT ,
)
def test_report_dont_list_failures ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
2024-11-13 09:19:10 +00:00
" Foo " ,
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
1 ,
2024-11-13 09:19:10 +00:00
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 0.02 " >
< testsuite name = " Bar " tests = " 1 " failures = " 1 " skipped = " 0 " time = " 0.02 " >
< testcase classname = " Bar/test_1 " name = " test_1 " time = " 0.02 " >
< failure > < ! [ CDATA [ Output goes here ] ] > < / failure >
< / testcase >
< / testsuite >
< / testsuites > """
)
)
] ,
list_failures = False ,
) ,
(
dedent (
""" \
# Foo
* 1 test failed
Failed tests and their output was too large to report . Download the build ' s log file to see the details. " " "
) ,
" error " ,
) ,
)
2024-12-11 09:46:34 +00:00
def test_report_dont_list_failures_link_to_log ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
2024-12-11 09:46:34 +00:00
" Foo " ,
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
1 ,
2024-12-11 09:46:34 +00:00
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 0.02 " >
< testsuite name = " Bar " tests = " 1 " failures = " 1 " skipped = " 0 " time = " 0.02 " >
< testcase classname = " Bar/test_1 " name = " test_1 " time = " 0.02 " >
< failure > < ! [ CDATA [ Output goes here ] ] > < / failure >
< / testcase >
< / testsuite >
< / testsuites > """
)
)
] ,
list_failures = False ,
buildkite_info = {
" BUILDKITE_ORGANIZATION_SLUG " : " organization_slug " ,
" BUILDKITE_PIPELINE_SLUG " : " pipeline_slug " ,
" BUILDKITE_BUILD_NUMBER " : " build_number " ,
" BUILDKITE_JOB_ID " : " job_id " ,
} ,
) ,
(
dedent (
""" \
# Foo
* 1 test failed
Failed tests and their output was too large to report . [ Download ] ( https : / / buildkite . com / organizations / organization_slug / pipelines / pipeline_slug / builds / build_number / jobs / job_id / download . txt ) the build ' s log file to see the details. " " "
) ,
" error " ,
) ,
)
2024-11-13 09:19:10 +00:00
def test_report_size_limit ( self ) :
self . assertEqual (
2025-03-27 12:59:43 -07:00
generate_test_report_lib . generate_report (
2024-11-13 09:19:10 +00:00
" Foo " ,
[ci] Handle the case where all reported tests pass but the build is still a failure (#120264)
In this build:
https://buildkite.com/llvm-project/github-pull-requests/builds/126961
The builds actually failed, probably because prerequisite of a test
suite failed to build.
However they still ran other tests and all those passed. This meant that
the test reports were green even though the build was red. On some level
this is technically correct, but it is very misleading in practice.
So I've also passed the build script's return code, as it was when we
entered the on exit handler, to the generator, so that when this happens
again, the report will draw the viewer's attention to the overall
failure. There will be a link in the report to the build's log file, so
the next step to investigate is clear.
It would be nice to say "tests failed and there was some other build
error", but we cannot tell what the non-zero return code was caused by.
Could be either.
The script handles the following situations now:
| Have Result Files? | Tests reported failed? | Return code | Report |
|--------------------|------------------------|-------------|-----------------------------------------------------------------------------|
| Yes | No | 0 | Success style report. |
| Yes | Yes | 0 | Shouldn't happen, but if it did, failure style report
showing the failures. |
| Yes | No | 1 | Failure style report, showing no failures but noting
that the build failed. |
| Yes | Yes | 1 | Failure style report, showing the test failures. |
| No | ? | 0 | No test report, success shown in the normal build
display. |
| No | ? | 1 | No test report, failure shown in the normal build
display. |
2025-01-13 09:05:18 +00:00
1 ,
2024-11-13 09:19:10 +00:00
[
junit_from_xml (
dedent (
""" \
< ? xml version = " 1.0 " encoding = " UTF-8 " ? >
< testsuites time = " 0.02 " >
< testsuite name = " Bar " tests = " 1 " failures = " 1 " skipped = " 0 " time = " 0.02 " >
< testcase classname = " Bar/test_1 " name = " test_1 " time = " 0.02 " >
< failure > < ! [ CDATA [ Some long output goes here . . . ] ] > < / failure >
< / testcase >
< / testsuite >
< / testsuites > """
)
)
] ,
size_limit = 128 ,
) ,
(
dedent (
""" \
# Foo
* 1 test failed
Failed tests and their output was too large to report . Download the build ' s log file to see the details. " " "
) ,
" error " ,
) ,
)