Skip to content

Enhance test deduplication in PyTorch test parsing - #4203

Open
Flamefire wants to merge 3 commits into
easybuilders:developfrom
Flamefire:pytorch-test-deduplication
Open

Enhance test deduplication in PyTorch test parsing#4203
Flamefire wants to merge 3 commits into
easybuilders:developfrom
Flamefire:pytorch-test-deduplication

Conversation

@Flamefire

Copy link
Copy Markdown
Contributor

Some tests have the full filename in their class name. This is partially accounted for in the suite_name == 'run_test' branch where the suite name is removed from the classname prefixes.
However, this is not enough. Depending on how the test is (re)run "regular" tests also have a prefix. E.g. from python-pytest/test_nestedtensor/test_nestedtensor-*.xml

<testcase classname="TestNestedTensorOpInfoCPU" name="test_nested_tensor_non_contiguous_mutation_cpu" time="4.2" file="test_nestedtensor.py"/>
<testcase classname="test.test_nestedtensor.TestNestedTensorOpInfoCPU" name="test_nested_tensor_non_contiguous_mutation_cpu" time="4.2"/>

Both refer to the same test and deduplication is essential in case one of those passed.
A common pattern is, that the short classnames (i.e. where only a classname is present, not a path-like) have the file attribute set.

For simplicity and to not rely on this quirk I moved the suite-prefix-stripping to all kinds of test results and also remove the last part of the suite which was previously not yet excluded. I.e. it could keep test_nestedtensor.TestNestedTensorOpInfoCPU. Seems that is not necessary and the class name alone should be enough.

This avoids failures like:

Counted failures of tests from the following test suites/files that are not contained in the summary output of PyTorch:
distributed/_composable/test_composability/test_pp_composability

The actual (reduced) sample that caused this failure is included in the tests now

The mentioned change is reflected in the test:

-            bar.test_foo.TestName.test_func1: success
+            test_foo.TestName.test_func1: success

Out of this:

    <testcase classname="test.dist.foo.bar.test_foo.TestName" name="test_func1" time="4.2" file="test_foo.py"/>
    <testcase classname="test.dist.foo.bar.test_foo.TestBar" name="test_func2" time="4.2" file="test_foo.py"/>
    <testcase classname="test.dist.foo.bar.test_2" name="test_func3" time="4.2" file="test_2.py"/>

The common prefix test.dist.foo.bar is treated as the suite name and now fully removed instead of keeping the last element.

Some tests have the full filename in their class name. This is partially
accounted for in the `suite_name == 'run_test'` branch where the suite
name is removed from the classname prefixes.
However, this is not enough. Depending on how the test is (re)run
"regular" tests also have a prefix. E.g. from `python-pytest/test_nestedtensor/test_nestedtensor-*.xml`
```
<testcase classname="TestNestedTensorOpInfoCPU" name="test_nested_tensor_non_contiguous_mutation_cpu" time="4.2" file="test_nestedtensor.py"/>
<testcase classname="test.test_nestedtensor.TestNestedTensorOpInfoCPU" name="test_nested_tensor_non_contiguous_mutation_cpu" time="4.2"/>
```
Both refer to the same test and deduplication is essential in case one
of those passed.
A common pattern is, that the short classnames (i.e. where only a
classname is present, not a path-like) have the `file` attribute set.

For simplicity and to not rely on this quirk I moved the
suite-prefix-stripping to all kinds of test results and also remove the
last part of the suite which was previously not yet excluded. I.e. it
could keep `test_nestedtensor.TestNestedTensorOpInfoCPU`.
Seems that is not necessary and the class name alone should be enough.
@Flamefire

Flamefire commented Aug 12, 2026

Copy link
Copy Markdown
Contributor Author

Test report by @Flamefire

Overview of tested easyconfigs (in order)

Aggregated manually
n1531.barnard.hpc.tu-dresden.de - Linux RHEL 9.6, x86_64, Intel(R) Xeon(R) Platinum 8470 (sapphirerapids), Python 3.9.25
See https://gist.github.com/Flamefire/b81797387315696907696be9306d32ad for a full test report.

When a XML entry considers a test as skipped it should be discarded if
there is an other entry, e.g. a success or failure which is more important.
However for tests marked as XFAIL (expected failure) the "success" is a
still marked as a skip but with an xfail type due to limitations of the format.
Hence it should be treated as success.
@Flamefire

Copy link
Copy Markdown
Contributor Author

Test report by @Flamefire

Overview of tested easyconfigs (in order)

  • SUCCESS PyTorch-2.0.1-foss-2022a.eb

  • SUCCESS PyTorch-2.0.1-foss-2022b.eb

Build succeeded for 2 out of 2 (total: 11 hours 49 mins 25 secs) (2 easyconfigs in total)
i8020 - Linux AlmaLinux 9.8, x86_64, AMD EPYC 7352 24-Core Processor (zen2), 8 x NVIDIA NVIDIA A100-SXM4-40GB, 580.159.04, Python 3.9.25
See https://gist.github.com/Flamefire/1fc03413e2c8701cbbb83a9a85669b05 for a full test report.

@Flamefire

Copy link
Copy Markdown
Contributor Author

Test report by @Flamefire

Overview of tested easyconfigs (in order)

  • SUCCESS PyTorch-2.1.2-foss-2022b-CUDA-12.0.0.eb

  • SUCCESS PyTorch-2.1.2-foss-2022b.eb

Build succeeded for 2 out of 2 (total: 20 hours 1 min 56 secs) (2 easyconfigs in total)
i8004 - Linux AlmaLinux 9.8, x86_64, AMD EPYC 7352 24-Core Processor (zen2), 8 x NVIDIA NVIDIA A100-SXM4-40GB, 580.159.04, Python 3.9.25
See https://gist.github.com/Flamefire/e853f8205f51dae7eb577704171ff4a5 for a full test report.

@Flamefire

Copy link
Copy Markdown
Contributor Author

Test report by @Flamefire

Overview of tested easyconfigs (in order)

  • SUCCESS PyTorch-2.1.2-foss-2023a-CUDA-12.1.1.eb

  • SUCCESS PyTorch-2.1.2-foss-2023a.eb

Build succeeded for 2 out of 2 (total: 20 hours 28 mins 9 secs) (2 easyconfigs in total)
i8020 - Linux AlmaLinux 9.8, x86_64, AMD EPYC 7352 24-Core Processor (zen2), 8 x NVIDIA NVIDIA A100-SXM4-40GB, 580.159.04, Python 3.9.25
See https://gist.github.com/Flamefire/6839e253bbf221cbba94f56c2a01f9be for a full test report.

@Flamefire

Copy link
Copy Markdown
Contributor Author

Test report by @Flamefire

Overview of tested easyconfigs (in order)

  • SUCCESS PyTorch-2.3.0-foss-2023b-CUDA-12.4.0.eb

  • SUCCESS PyTorch-2.3.0-foss-2023b.eb

Build succeeded for 2 out of 2 (total: 26 hours 21 mins 51 secs) (2 easyconfigs in total)
i8004 - Linux AlmaLinux 9.8, x86_64, AMD EPYC 7352 24-Core Processor (zen2), 8 x NVIDIA NVIDIA A100-SXM4-40GB, 580.159.04, Python 3.9.25
See https://gist.github.com/Flamefire/ac83ff8ae08cd14424367a55155f59d9 for a full test report.

@Flamefire

Flamefire commented Aug 15, 2026

Copy link
Copy Markdown
Contributor Author

Test report by @Flamefire

Overview of tested easyconfigs (in order)

Build succeeded for 1 out of 2 (total: 32 hours 1 min 32 secs) (2 easyconfigs in total)
i8020 - Linux AlmaLinux 9.8, x86_64, AMD EPYC 7352 24-Core Processor (zen2), 8 x NVIDIA NVIDIA A100-SXM4-40GB, 580.159.04, Python 3.9.25
See https://gist.github.com/Flamefire/0efe3bbed55ba2c394cc4e1d11ff5549 for a full test report.

@Flamefire

Flamefire commented Aug 17, 2026

Copy link
Copy Markdown
Contributor Author

Test report by @Flamefire

Overview of tested easyconfigs (in order)

Build succeeded for 1 out of 3 (total: 69 hours 20 mins 4 secs) (3 easyconfigs in total)
i8036 - Linux AlmaLinux 9.8, x86_64, AMD EPYC 7352 24-Core Processor (zen2), 8 x NVIDIA NVIDIA A100-SXM4-40GB, 580.159.04, Python 3.9.25
See https://gist.github.com/Flamefire/1ef5c3f190f0bf6d983457d590295a46 for a full test report.

@boegel boegel added this to the next release (5.4.1?) milestone Aug 26, 2026
@boegel

boegel commented Aug 26, 2026

Copy link
Copy Markdown
Member

@Flamefire Can you look into the failed test reports? Not sure they should be blocking the PR...

@Flamefire

Copy link
Copy Markdown
Contributor Author

I'll look into one failure but they are all unrelated to this change here. I added comments for each

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