Conversation
| if job_key in seen: | ||
| return None | ||
| seen.add(job_key) | ||
| job = jobs.get(job_key, {}) |
There was a problem hiding this comment.
Can we confirm that the job_key will have the value linux-jammy-rocm-py3_10-build and not linux-jammy-rocm-py3.10-mi350 in trunk.yml?
There was a problem hiding this comment.
Confirmed. _matrix_for_job_prefix matches either the displayed name or YAML key, but it deliberately carries (key, job) and passes key into _literal_test_matrix. For trunk, that means job_key is the YAML identifier such as linux-jammy-rocm-py3_10-build, while linux-jammy-rocm-py3.10-mi350 is only used to select that job by its displayed name. I exercised the updated helper against trunk.yml at upstream SHA cf18dda7; it followed the build job output and resolved a non-empty default matrix. I also added workflow-run and architecture scoping in 71e3f00 so same-SHA workflows cannot contribute an unrelated prefix.
## Summary - replace the retired `nightly` parity key with `preview` - match the live daily `rocm-preview` `linux-noble-rocm-preview-py3.12-mi350` jobs - use the current 8/3/2 default/distributed/inductor fallback matrix This clean replacement is based on current `develop`; it supersedes #3406, whose pre-reset history cannot merge without a force-push or unrelated-history merge. ## Test plan - [x] Parse parity config JSON - [x] Compile `download_testlogs` - [x] Parse `parity.yml` as YAML - [x] Verify all 13 test jobs against scheduled [pytorch/pytorch run 31344407133](https://github.com/pytorch/pytorch/actions/runs/31344407133) - [x] Run end-to-end Preview parity dispatch ## Dependencies Land this before the Preview auto-trigger update in #3555 and before retargeting the operational parity PRs. Made with [Cursor](https://cursor.com) ## Alignment landing order This is the root dependency. After it lands, retarget the stacked PRs to `develop` in this order: 1. #3535 dynamic workflow/prefix/shard discovery 2. #3536 canonical per-shard job URLs 3. #3523 consolidated classifier rules (independent base; may land earlier) 4. #3559 variant-run filtering 5. #3558 graceful missing-config handling 6. #3557 partial-report preservation 7. #3560 authoritative flaky attribution 8. #3556 latest-SHA resolution 9. #3555 scheduled multi-architecture automation last Validation: full Preview [run 31506711303](https://github.com/ethanwee1/pytorch/actions/runs/31506711303) and combined Preview+MI350 [run 31507307756](https://github.com/ethanwee1/pytorch/actions/runs/31507307756) both succeeded on matching SHA `cf18dda7`. ## August 25 refresh - Merged current ROCm `develop` and reran JSON, Python, and workflow YAML validation. - The previously documented Preview and combined Preview+MI350 runs satisfy the end-to-end checklist item.
| 'mi350': ('mi350',), | ||
| 'navi31': ('navi31',), | ||
| 'preview': ('rocm-preview',), | ||
| } |
There was a problem hiding this comment.
Can we revisit to see if this is still needed? Would rather reduce a mapping if not required.
There was a problem hiding this comment.
Fixed in 0e842a4. The architecture-token map was redundant because candidates are already restricted to the selected workflow run and its nested reusable runs. I removed the map and the arch plumbing, and updated the fuzzy matcher unit tests; all 4 pass.
Read CUDA and ROCm shard totals from workflow YAML at the tested commit, self-heal renamed job prefixes, and follow reusable-workflow artifacts to their hosting run.
Prevent same-SHA jobs from another ROCm workflow from self-healing to the wrong prefix by traversing nested reusable runs and filtering candidates by architecture.
Keep static fallbacks aligned with current CUDA and MI300 topology while dynamic workflow discovery remains authoritative.
0d3654e to
17d0944
Compare
| { "workflow": "trunk", "job_prefix": "linux-jammy-rocm-py3.10-mi350" } | ||
| ], | ||
| "shard_counts": { "default": 8, "distributed": 3, "inductor": 2 }, | ||
| "shard_counts": { "default": 8, "distributed": 5, "inductor": 2 }, |
There was a problem hiding this comment.
There was a problem hiding this comment.
Correct. The current rebased head keeps MI350 at 8/3/2; the 8/5/2 hunk was from the superseded pre-rebase commit. Commit 0044547 restores the live counts, while MI300 remains 8/5/2 from periodic-rocm-mi300.yml.
| "inductor": [{ "workflow": "inductor", "job_prefix": "unit-test / inductor-test" }], | ||
| "test_kinds": ["test-osdc", "test"], | ||
| "shard_counts": { "default": 14, "distributed": 10, "inductor": 2 }, | ||
| "shard_counts": { "default": 5, "distributed": 3, "inductor": 2 }, |
There was a problem hiding this comment.
These counts were correct originally: https://github.com/pytorch/pytorch/blob/96ceb08175be9720b7aa6da80ba2b5b52429bd8a/.github/workflows/trunk.yml#L251
There was a problem hiding this comment.
Correct. Commit 0044547 restores CUDA to the live trunk fallback counts 14/10/2. Runtime workflow discovery remains authoritative if those values drift again.
Match the current upstream trunk topology while retaining runtime workflow discovery as the authoritative source.
Extract the self-healing prefix matcher into a testable module and run its focused unit suite before every parity matrix launch.
Remove the redundant architecture token map because candidates are already restricted to the selected workflow and its nested reusable runs.
Summary
num_shardsvalues from the authoritative test matrixWhy
parity_job_config.jsonremainsThe workflow YAML is now authoritative for shard counts, but the JSON still supplies information that cannot yet be discovered from one resolved workflow file: the ordered workflow candidates and architecture-specific fallbacks, seed job prefixes used to locate the right family before self-healing, CUDA test-job kinds, and check-run/workflow regexes used by
parity-auto.ymlbefore dispatch. Removing the file now would require moving those hardcoded values elsewhere or separately redesigning workflow discovery and gating; it would not actually remove the configuration. A follow-up can remove the JSON once those remaining consumers derive their topology dynamically.Test plan
Preview topology update
This branch now uses
previewonly and validates topology discovery against the scheduledrocm-previewmi3508/3/2 lane. #3554 owns the canonical Preview config; the duplicate Preview config hunks were removed while stacking on refreshed #3554. This PR remains the prerequisite for #3536 and #3555.Prefix safety update
Ported the fork #6 safety fix in
71e3f00d61f: check-runs are scoped to the selected workflow and nested reusable runs, candidates are ROCm-only and scoped to the selected workflow run, and Preview uses a distinctrocm-previewtoken.Validation covers Python compilation, live trunk/Preview YAML matrix resolution at upstream SHA
cf18dda7, scoped check-run selection, and exclusion of non-ROCm candidates.Alignment landing order
Depends on #3554. Land before #3536 and before downloader resilience/automation PRs. Prefix safety includes nested reusable-run scoping and workflow-run filtering; validated against live trunk and Preview workflow YAML at
cf18dda7.August 25 refresh
Stacked on refreshed [CI] Parity: replace ROCm nightly with scheduled Preview #3554 and resolved the Preview matcher conflict.
Removed duplicate workflow changes; the focused diff is downloader discovery, config fallbacks, and PyYAML.
Updated fallback shards to CUDA 14/10/2, MI300 8/5/2, and MI200 10/3/4, verified against current upstream workflow matrices.
Revalidated Python compilation, JSON, and workflow YAML parsing.
Fuzzy job-name unit gate
Extracted fuzzy ROCm job-prefix selection into
job_name_match.py.Added four unit cases covering rename recovery, exact-match priority, CUDA exclusion, and no-match fallback.
parity.ymlnow runs the suite once inparity-unit-tests;generate-paritycannot start unless it passes.Local result: 4 tests passed; Python compilation and actionlint passed (excluding the workflow’s pre-existing legacy input-count warning).
Parity stack merge order
All open parity PRs are targeted to
develop. Merge in this order:#3259 is a separate follow-up: reconstruct FrameworkWeb ingestion after the operational stack lands.