-
Notifications
You must be signed in to change notification settings - Fork 429
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
fix(ci_visibility): count failed/skipped tests in JUnit XML when retries are enabled #12862
fix(ci_visibility): count failed/skipped tests in JUnit XML when retries are enabled #12862
Conversation
This reverts commit f01ab68.
|
Bootstrap import analysisComparison of import times between this PR and main. SummaryThe average import time in this PR is: 238 ± 5 ms. The average import time in main is: 242 ± 4 ms. The import time difference between this PR and main is: -4.3 ± 0.2 ms. Import time breakdownThe following import paths have shrunk:
|
BenchmarksBenchmark execution time: 2025-03-26 10:15:10 Comparing candidate commit cd95bfa in PR branch Found 3 performance improvements and 0 performance regressions! Performance is the same for 487 metrics, 2 unstable metrics. scenario:iast_aspects-format_map_aspect
scenario:iast_aspects-replace_aspect
scenario:iastdjangostartup-iast
|
Co-authored-by: Federico Mon <federico.mon@datadoghq.com>
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-3.1 3.1
# Navigate to the new working tree
cd .worktrees/backport-3.1
# Create a new branch
git switch --create backport-12862-to-3.1
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 2a506fb25a1bb5791f703329624cd18858dd357d
# Push it to GitHub
git push --set-upstream origin backport-12862-to-3.1
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-3.1 Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-3.2 3.2
# Navigate to the new working tree
cd .worktrees/backport-3.2
# Create a new branch
git switch --create backport-12862-to-3.2
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 2a506fb25a1bb5791f703329624cd18858dd357d
# Push it to GitHub
git push --set-upstream origin backport-12862-to-3.2
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-3.2 Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-3.3 3.3
# Navigate to the new working tree
cd .worktrees/backport-3.3
# Create a new branch
git switch --create backport-12862-to-3.3
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 2a506fb25a1bb5791f703329624cd18858dd357d
# Push it to GitHub
git push --set-upstream origin backport-12862-to-3.3
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-3.3 Then, create a pull request where the |
…ies are enabled (#12862) The pytest JUnit XML plugin uses the test report's [`failed`](https://github.com/pytest-dev/pytest/blob/8.3.x/src/_pytest/junitxml.py#L562) and [`longrepr`](https://github.com/pytest-dev/pytest/blob/8.3.x/src/_pytest/junitxml.py#L201) properties to count failed tests and include them in the output. Because retried tests have their own special statuses (`dd_efd_final_failed`, etc), they don't count as failures, and are excluded from the JUnit XML count. This PR creates a subclass of TestReport that is aware of those special statuses and reports them as passed/failed/skipped accordingly. This is honestly a bit of a hack. It would probably be best to rewrite the retry logic entirely so it would use normal pytest states, and pass the information that they are retries in some other way. But that will take more time, and I would like to fix the bug sooner rather than later. The exception information for the initial attempt is included in the JUnit XML. Known issue: quarantined failing tests are not counted. The way forward with this is to rewrite the retry logic, which I plan to do in a future PR. - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) --------- Co-authored-by: Federico Mon <federico.mon@datadoghq.com> (cherry picked from commit 2a506fb)
…ies are enabled (#12862) The pytest JUnit XML plugin uses the test report's [`failed`](https://github.com/pytest-dev/pytest/blob/8.3.x/src/_pytest/junitxml.py#L562) and [`longrepr`](https://github.com/pytest-dev/pytest/blob/8.3.x/src/_pytest/junitxml.py#L201) properties to count failed tests and include them in the output. Because retried tests have their own special statuses (`dd_efd_final_failed`, etc), they don't count as failures, and are excluded from the JUnit XML count. This PR creates a subclass of TestReport that is aware of those special statuses and reports them as passed/failed/skipped accordingly. This is honestly a bit of a hack. It would probably be best to rewrite the retry logic entirely so it would use normal pytest states, and pass the information that they are retries in some other way. But that will take more time, and I would like to fix the bug sooner rather than later. The exception information for the initial attempt is included in the JUnit XML. Known issue: quarantined failing tests are not counted. The way forward with this is to rewrite the retry logic, which I plan to do in a future PR. - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) --------- Co-authored-by: Federico Mon <federico.mon@datadoghq.com> (cherry picked from commit 2a506fb)
…ies are enabled (#12862) The pytest JUnit XML plugin uses the test report's [`failed`](https://github.com/pytest-dev/pytest/blob/8.3.x/src/_pytest/junitxml.py#L562) and [`longrepr`](https://github.com/pytest-dev/pytest/blob/8.3.x/src/_pytest/junitxml.py#L201) properties to count failed tests and include them in the output. Because retried tests have their own special statuses (`dd_efd_final_failed`, etc), they don't count as failures, and are excluded from the JUnit XML count. This PR creates a subclass of TestReport that is aware of those special statuses and reports them as passed/failed/skipped accordingly. This is honestly a bit of a hack. It would probably be best to rewrite the retry logic entirely so it would use normal pytest states, and pass the information that they are retries in some other way. But that will take more time, and I would like to fix the bug sooner rather than later. The exception information for the initial attempt is included in the JUnit XML. Known issue: quarantined failing tests are not counted. The way forward with this is to rewrite the retry logic, which I plan to do in a future PR. - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) --------- Co-authored-by: Federico Mon <federico.mon@datadoghq.com> (cherry picked from commit 2a506fb)
…ies are enabled (#12862) The pytest JUnit XML plugin uses the test report's [`failed`](https://github.com/pytest-dev/pytest/blob/8.3.x/src/_pytest/junitxml.py#L562) and [`longrepr`](https://github.com/pytest-dev/pytest/blob/8.3.x/src/_pytest/junitxml.py#L201) properties to count failed tests and include them in the output. Because retried tests have their own special statuses (`dd_efd_final_failed`, etc), they don't count as failures, and are excluded from the JUnit XML count. This PR creates a subclass of TestReport that is aware of those special statuses and reports them as passed/failed/skipped accordingly. This is honestly a bit of a hack. It would probably be best to rewrite the retry logic entirely so it would use normal pytest states, and pass the information that they are retries in some other way. But that will take more time, and I would like to fix the bug sooner rather than later. The exception information for the initial attempt is included in the JUnit XML. Known issue: quarantined failing tests are not counted. The way forward with this is to rewrite the retry logic, which I plan to do in a future PR. - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) --------- Co-authored-by: Federico Mon <federico.mon@datadoghq.com> (cherry picked from commit 2a506fb)
The pytest JUnit XML plugin uses the test report's
failed
andlongrepr
properties to count failed tests and include them in the output. Because retried tests have their own special statuses (dd_efd_final_failed
, etc), they don't count as failures, and are excluded from the JUnit XML count. This PR creates a subclass of TestReport that is aware of those special statuses and reports them as passed/failed/skipped accordingly.This is honestly a bit of a hack. It would probably be best to rewrite the retry logic entirely so it would use normal pytest states, and pass the information that they are retries in some other way. But that will take more time, and I would like to fix the bug sooner rather than later.
One limitation of this approach is that the exception information from the failing retries is not included in the final report, and therefore don't show up in the JUnit XML.The exception information for the initial attempt is included in the JUnit XML.Known issue: quarantined failing tests are not counted. The way forward with this is to rewrite the retry logic, which I plan to do in a future PR.
Checklist
Reviewer Checklist