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

fix(ci_visibility): count failed/skipped tests in JUnit XML when retries are enabled #12862

Merged
merged 15 commits into from
Mar 26, 2025

Conversation

vitor-de-araujo
Copy link
Contributor

@vitor-de-araujo vitor-de-araujo commented Mar 24, 2025

The pytest JUnit XML plugin uses the test report's failed and longrepr 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

  • 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
  • The change includes or references documentation updates if necessary
  • Backport labels are set (if applicable)

Reviewer Checklist

  • 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 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

Copy link
Contributor

github-actions bot commented Mar 24, 2025

CODEOWNERS have been resolved as:

releasenotes/notes/ci_visibility-fix-junit-xml-retry-count-65de6ad6b9bb35d2.yaml  @DataDog/apm-python
ddtrace/contrib/internal/pytest/_atr_utils.py                           @DataDog/ci-app-libraries
ddtrace/contrib/internal/pytest/_attempt_to_fix.py                      @DataDog/ci-app-libraries
ddtrace/contrib/internal/pytest/_efd_utils.py                           @DataDog/ci-app-libraries
ddtrace/contrib/internal/pytest/_plugin_v2.py                           @DataDog/ci-app-libraries
ddtrace/contrib/internal/pytest/_retry_utils.py                         @DataDog/ci-app-libraries
tests/contrib/pytest/test_pytest_atr.py                                 @DataDog/ci-app-libraries
tests/contrib/pytest/test_pytest_attempt_to_fix.py                      @DataDog/ci-app-libraries
tests/contrib/pytest/test_pytest_efd.py                                 @DataDog/ci-app-libraries

Copy link
Contributor

github-actions bot commented Mar 24, 2025

Bootstrap import analysis

Comparison of import times between this PR and main.

Summary

The 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 breakdown

The following import paths have shrunk:

ddtrace.auto 2.189 ms (0.92%)
ddtrace.bootstrap.sitecustomize 1.467 ms (0.62%)
ddtrace.bootstrap.preload 1.467 ms (0.62%)
ddtrace.internal.products 1.467 ms (0.62%)
ddtrace.internal.remoteconfig.client 0.701 ms (0.29%)
ddtrace 0.722 ms (0.30%)

@pr-commenter
Copy link

pr-commenter bot commented Mar 24, 2025

Benchmarks

Benchmark execution time: 2025-03-26 10:15:10

Comparing candidate commit cd95bfa in PR branch vitor-de-araujo/SDTEST-1742/junit-retry-failures with baseline commit 5c8fb46 in branch main.

Found 3 performance improvements and 0 performance regressions! Performance is the same for 487 metrics, 2 unstable metrics.

scenario:iast_aspects-format_map_aspect

  • 🟩 execution_time [-1.212µs; -1.175µs] or [-24.244%; -23.510%]

scenario:iast_aspects-replace_aspect

  • 🟩 execution_time [-1.377µs; -1.335µs] or [-20.828%; -20.192%]

scenario:iastdjangostartup-iast

  • 🟩 execution_time [-2.038s; -2.009s] or [-46.246%; -45.587%]

Co-authored-by: Federico Mon <federico.mon@datadoghq.com>
@vitor-de-araujo vitor-de-araujo merged commit 2a506fb into main Mar 26, 2025
366 of 367 checks passed
@vitor-de-araujo vitor-de-araujo deleted the vitor-de-araujo/SDTEST-1742/junit-retry-failures branch March 26, 2025 10:40
Copy link
Contributor

The backport to 3.1 failed:

The process '/usr/bin/git' failed with exit code 1

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 base branch is 3.1 and the compare/head branch is backport-12862-to-3.1.

Copy link
Contributor

The backport to 3.2 failed:

The process '/usr/bin/git' failed with exit code 1

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 base branch is 3.2 and the compare/head branch is backport-12862-to-3.2.

Copy link
Contributor

The backport to 3.3 failed:

The process '/usr/bin/git' failed with exit code 1

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 base branch is 3.3 and the compare/head branch is backport-12862-to-3.3.

vitor-de-araujo added a commit that referenced this pull request Mar 26, 2025
…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)
vitor-de-araujo added a commit that referenced this pull request Mar 26, 2025
…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)
vitor-de-araujo added a commit that referenced this pull request Mar 26, 2025
…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)
vitor-de-araujo added a commit that referenced this pull request Mar 26, 2025
…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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants