[bvolpato]

Description

Motivation. C++ test groups share a build directory. The retry helper selects the first results-*.xml file there, which can belong to an earlier group. The retry then overwrites the actual target report with only the retried results, losing previously passing results and misattributing parallelism metadata.

Change. Use the report explicitly named by the current CTest command's --output-junit argument for retry merging and metadata. An unrelated report cannot substitute for an absent target report.

Verified before/after. In a real CPU CTest reproduction, results-common.xml already exists when a kernels group runs. The kernel-flaky-recovered case fails initially and passes on retry:

Result after retry	Before	After
Previously passing kernel-pass result	Missing from the kernels report	Retained with the recovered result
Earlier common report	Incorrectly receives the kernels run's parallelism metadata	Unchanged
Target report absent after a failed run	Unrelated report can enter retry handling	Original failure propagates

The verified gain is complete, correctly attributed test results after recovery. Effects on Jenkins runtime and failure frequency remain unmeasured.

Test Coverage

• Focused CPU regressions cover retry-report completeness and a missing target report alongside an unrelated existing report. They fail against the original source and pass with this change on Python 3.12 with pytest 8.4.2.
• A real CPU CTest reproduction verifies that the passing target result survives a successful retry and that the earlier group's report stays unchanged.
• Scoped pre-commit and git diff --check pass. The existing unittest/tools CPU CI entry covers the regression module.
• GPU C++ suites and Jenkins were not run locally.

PR Checklist

Please review the following before submitting your PR:

• PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.

• PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.

• Test cases are provided for new code paths (see test instructions)

• If PR introduces API changes, an appropriate PR label is added - either api-compatible or api-breaking. For api-breaking, include BREAKING in the PR title.

• Any new dependencies have been scanned for license and vulnerabilities

• CODEOWNERS updated if ownership changes

• Documentation updated as needed

• Update tava architecture diagram if there is a significant design change in PR.

• The reviewers assigned automatically/manually are appropriate for the PR.

• Please check this after reviewing the above items as appropriate for this PR.

GitHub Bot Help

To see a list of available CI bot commands, please comment /bot help.