[CI] Parity: carry commit SHA labels through log + running-time parsing

[ethanwee1]

Split out of #3210 (1 of 3) for easier review.

Consumer-side support for commit-vs-commit parity (baseline_sha mode):

• detect_log_failures.py: preserve the short commit-SHA prefix on log filenames (e.g. 09e0c59b_rocm3.txt) as the platform label, matching the SHA-prefixed filenames download_testlogs produces in baseline mode.
• summarize_xml_testreports.py: name the per-test-file running-time CSV columns from the resolved set names (set1/set2) instead of hardcoded rocm_/cuda_, and add per-config test-shard counts.

The download_testlogs run-selection side of the original commit already landed in develop via #3278, so this PR carries only the remaining consumer-side parsing changes.

Made with Cursor

---

Rebased onto current develop + validated

This PR was rebased onto current develop (it was previously opened against an old lineage and showed unrelated files). Validation parity run on the clean SHA ba9910c6 (mi300): https://github.com/ethanwee1/pytorch/actions/runs/28884939416

Commit-vs-commit validation (SHA labels)

Parity run ba9910c6 vs 8b3ff3b4 (mi300): https://github.com/ethanwee1/pytorch/actions/runs/28888069456 — confirms labels follow the two SHAs (e.g. BA9910C6ONLY, SKIPPED (on ba9910c6, but not on 8b3ff3b4)).

[rocm-repo-management-api]

Jenkins build for 1f07ad538148fd18634c2375c520d91165424255 commit finished as FAILURE
Links: Pipeline Overview / Build artifacts / Test Results

[jithunnair-amd]

I don't know how far you want to take this "secularizing" of set1/set2 naming instead of ROCm/CUDA, but there are still many occurrences in the file that refer to ROCm/CUDA. Just something to keep in mind if you really want to make everything consistent. Not everything in this PR probably.

[ethanwee1]

Agreed — I've kept this PR scoped to the user-facing output: the running-time CSV columns and the printed summary now both follow set1/set2. The remaining ROCm/CUDA occurrences are internal variable names (test_file_level_ROCm, *_DEFAULT counters, etc.); I left those untouched to keep the diff focused, and we can do a broader internal rename as a separate cleanup if you'd prefer.

[jithunnair-amd]

Even if we restrict this PR's secularization of set1/set2 to just user-facing stuff, then this seems to also be a candidate for being updated, since this is still printing as ROCm/CUDA

[ethanwee1]

Done in 96845a7 — the printed summary headers now derive from set1_name/set2_name too, so they stay consistent with the CSV columns. Normal-mode output is unchanged (ROCMONLY_DEFAULT, CUDA_DEFAULT, ROCM_DEFAULT / ROCM_RUNNING_TIME, CUDA_RUNNING_TIME); in commit-vs-commit mode they now show the SHA labels instead of mislabeling them ROCm/CUDA.

[jithunnair-amd]

Please change any user-facing parts of the script to remove the ROCm/CUDA hardcoding (variable names can wait for another PR, if desired).

Also, IIUC, this PR is trying to service the sha-vs-baseline-sha use-case. If so, please mention a validation run so that reviewers can verify the output.

[rocm-repo-management-api]

Jenkins build for 96845a7bbc10d9d44402cc9b05af3f42bc87d7e1 commit finished as FAILURE
Links: Pipeline Overview / Build artifacts / Test Results

[rocm-repo-management-api]

Jenkins build for bfaa5c6f029a7bb007467c4b4d574c05459e1cce commit finished as ABORTED
Links: Pipeline Overview / Build artifacts / Test Results

Detected error during Pytorch building:

-- HIP architectures: gfx90a;gfx908;gfx942;gfx1033
CMake Warning (dev) at /opt/rocm/lib/cmake/hip/hip-config-amd.cmake:98 (message):
   GPU_TARGETS was not set, and system GPU detection was unsuccsessful.
   
   The amdgpu-arch tool failed:
   Error: 'Failed to get device count'
   Output: ''
   
   As a result, --offload-arch will not be set for subsequent
   compilations, and the default architecture
   (gfx906 for dynamic build / gfx942 for static build) will be used

[ethanwee1]

Thanks for the review. Addressed:

• User-facing ROCm/CUDA hardcoding removed. The printed summary labels and the running-time CSV column headers now follow the set1/set2 naming (which default to rocm/cuda, or become the two commit short-SHAs in commit-vs-commit mode). The remaining ROCm/CUDA tokens are internal variable names only, which I've left for a follow-up per your note.
• Validation run (commit-vs-commit / sha-vs-baseline_sha), mi300: https://github.com/ethanwee1/pytorch/actions/runs/28888069456 — ba9910c6 vs 8b3ff3b4. The output labels come out SHA-based, e.g.:
  • SKIPPED (on ba9910c6, but not on 8b3ff3b4)
  • BA9910C6ONLY (PASSED on BA9910C6, NOT PASSED on 8B3FF3B4)
  • DISAGREE [(SKIPPED+MISSED)/8B3FF3B4] %