Repository navigation
fix(ci): test shared BLAS changes in multi-arch CI - #11667
Conversation
Co-authored-by: Cursor <cursoragent@cursor.com>
✅ All Checks Passed — Ready for Review
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🎉 All checks passed! This PR is ready for review. |
There was a problem hiding this comment.
🟢 Approval recommended
The workflow wiring and the new mapping script are consistent with the existing therock_matrix.py mapping source-of-truth and are covered by targeted unit tests that enforce the intended selection and fail-closed behavior.
Pull request overview
This PR adjusts the rocm-libraries default TheRock multi-arch CI workflow to derive a dedicated “test projects” list (based on the existing therock_matrix.py mapping) before invoking downstream Linux/Windows multi-arch workflows, preventing shared/* subtree changes from silently falling back to sanity-only coverage.
Changes:
- Add a CI-side mapping step (
multi_arch_test_projects.py) to translateshared/*changed subtrees into TheRock-recognized test project names, failing closed for unmapped shared paths. - Update the multi-arch workflow to pass the derived
test_projectsto downstream TheRock multi-arch workflows while preserving the originalchanged_projectsfor stage impact / artifact reuse logic. - Add focused unit tests covering shared-subtree mappings, deduplication behavior, and the fail-closed contract.
File summaries
| File | Description |
|---|---|
.github/workflows/therock-multi-arch-ci.yml |
Adds a “Select multi-arch test projects” step and routes downstream changed_projects to the derived test-project list. |
.github/scripts/multi_arch_test_projects.py |
Implements the shared-subtree → test-project selection logic using the existing therock_matrix.py mapping and emits test_projects for workflows. |
.github/scripts/tests/multi_arch_test_projects_test.py |
Adds regression tests validating mappings for shared BLAS-related subtrees and fail-closed behavior. |
.github/scripts/DEVELOPMENT.md |
Documents the new script and its tests in the .github/scripts developer guide. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Validated this fix by replaying the original false-green case against it: #11669 is a throwaway draft PR that takes this fix as its base, reverts it back out, then re-applies the exact That isolates the diff to just the stinkytofu files, so the only thing that changed between "before" and "after" is this mapping fix. The Previously |
jayhawk-commits
left a comment
There was a problem hiding this comment.
LGTM
Will make changes on TheRock side to address these gaps, but this works for the short-term.
…ostsubmit + nightly) (#11677) ## Summary Restores gfx125X (CDNA5/gfx1250) build-only coverage that was silently dropped when #11542 made "TheRock Multi-Arch CI" the default, replacing the legacy single-arch "TheRock CI" (now opt-in via `ci:single-arch` label / `workflow_dispatch`). Legacy `therock-ci.yml` built `gfx94X, gfx950, gfx125X` on every PR and push, gfx125X build-only by deliberate design (9fa5244 -- "add gfx125X build gating with deferred test enablement"). The new default `therock-multi-arch-ci.yml` only builds `gfx94X, gfx950` -- gfx125X coverage was lost entirely, not moved anywhere. No GPU test hardware exists for gfx1250 anywhere in CI yet (see #11675), so this only restores build validation, not test execution -- but that is exactly what the legacy default provided too. Two commits: 1. Add `gfx125X` build-only to `therock-multi-arch-ci-nightly.yml`'s Linux family list. 2. Add `gfx125X` build-only to `therock-multi-arch-ci.yml`'s default Linux family list, restoring per-PR/push parity with the legacy default (so gfx1250 build breaks are caught same-PR, not up to ~24h later at nightly). The Windows family default also changed in the same migration (`gfx1151` -> `gfx110X`), but that is not a regression -- `gfx110X` gets real test execution on presubmit, while `gfx1151` was build-only there too (`nightly_check_only_for_family` gates its tests to schedule/dispatch in TheRock's own family matrix). `gfx1151` nightly coverage for rocm-libraries is already intact in `therock-multi-arch-ci-nightly.yml`. ## Testing - Validated YAML syntax and ran `pre-commit run --files <each changed workflow>` (all hooks pass) on both commits. - No test-suite changes needed. This is workflow-input-only. - Will confirm on the next PR/push run (and the next scheduled nightly, or a manual `workflow_dispatch`) that a `gfx125X` build shard appears and completes in both workflows. ## Related - Tracking issue: #11675 - Prior BLAS test-selection fix in Multi-Arch CI: #11667 - Migration that dropped this coverage: #11542 - Original gfx125X build-gating design: 9fa5244 --------- Co-authored-by: Cursor <cursoragent@cursor.com>
TheRock Submodule Bump ActivityNewest first
|
The workflows and scripts that decide which test suites and GPU families run on every pull request are currently owned by the general /.github/ rule. A change to them silently changes test coverage for the math libraries teams without requiring their review. That happened in #11542, which made Multi-Arch CI the default gate. It was approved by four reviewers, none of whom belonged to any math libraries team, and it dropped BLAS test selection for shared/ subtrees and gfx125X build coverage. Both required follow-up fixes (#11667, #11677), and gfx1250 pre-submit coverage is still not restored. Assign these paths solely to @ROCm/rocm-math-lib-build-infra so a math libraries owner must approve changes to them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
## Problem PR #11667 added a translation layer (`multi_arch_test_projects.py` + `therock_matrix.py`'s `shared/*` entries) so Multi-Arch CI could map `shared/*` monorepo subtrees (e.g. `shared/tensile`, `shared/origami`) to the right TheRock test projects, back when TheRock's own selector had no notion of these paths. TheRock's `test_tools/determine_rocm_test_dependencies.py` now natively resolves all five `shared/*` paths (confirmed already in the pinned ref, `df3d451a`), so the rocm-libraries-side pre-resolution step is redundant: raw `shared/*` paths can now pass straight through to TheRock's selector, exactly like every `projects/*` path already does. Tracked in #11784 (the remaining follow-up item from that issue), following #11785. ## Changes - **Deleted** `.github/scripts/multi_arch_test_projects.py` and its test file. This script's only caller was `therock-multi-arch-ci.yml`'s "Select multi-arch test projects" step. - **`therock-multi-arch-ci.yml`**: removed that step; `test_projects` now comes straight from `steps.configure.outputs.changed_projects`. Trimmed the now-unused `ci_utils.py`/`therock_matrix.py` sparse-checkout entries from the same job. - **`therock_matrix.py`'s `shared/*` entries in `subtree_to_project_map` are intentionally left untouched** -- they're still required by `therock_configure_ci.py` (the opt-in `ci:single-arch` legacy path), which never calls TheRock's native selector. ## Behavior delta (verified against the exact pinned TheRock commit, `df3d451a`) Ran `determine_rocm_test_dependencies.py` locally for all five `shared/*` paths, before (today's `multi_arch_test_projects.py` output) vs. after (native selector, default per-component levels, no CLI override): | Changed path | Before (legacy) | After (native) | Delta | |---|---|---|---| | `shared/origami` | hipblas, hipblaslt, origami, rocblas, tensilelite | hipblas, hipblaslt, hipblasltprovider, hipdnn-samples, hipsolver, hipsparse, hipsparselt, miopen, miopenprovider, origami, rocalution, rocblas, rocsolver, rocsparse, rocwmma, tensilelite | superset -- safe | | `shared/stinkytofu` | hipblas, hipblaslt, rocblas, tensilelite | hipblas, hipblaslt, hipblasltprovider, hipdnn-samples, hipsolver, hipsparse, hipsparselt, miopen, miopenprovider, rocalution, rocblas, rocsolver, rocsparse, rocwmma, tensilelite | superset -- safe | | `shared/mxdatagenerator` | hipblas, hipblaslt, rocblas, rocroller, tensilelite | hipblas, hipblaslt, hipblasltprovider, hipdnn, hipdnn-samples, hipsolver, hipsparse, hipsparselt, miopen, miopenprovider, rocalution, rocblas, rocroller, rocsolver, rocsparse, rocwmma, tensilelite | superset -- safe | | `shared/rocroller` | rocroller | hipblaslt, hipdnn, miopen, rocroller | superset -- safe | | `shared/tensile` | hipblas, hipblaslt, rocblas, tensilelite | hipblas, hipsolver, miopen, rocalution, rocblas, rocsolver, rocsparse, rocwmma | **narrows**: drops hipblaslt, tensilelite; adds hipsolver, miopen, rocalution, rocsolver, rocsparse, rocwmma | **On the `shared/tensile` narrowing:** checked `test_tools/therock_consumer_graph.json` -- `rocblas`'s consumers do not include `hipblaslt` (the edge runs the other way: `hipblaslt` consumes `rocblas`, not vice versa), so `hipblaslt`/`tensilelite` don't architecturally depend on `shared/tensile` changes. Accepting this as a correctness fix rather than papering over it with a manual addition, per architecture. ## Testing - `pytest .github/scripts/tests` -- 144 passed, 8 xfailed (pre-existing, unrelated) - `pre-commit run` on both changed files -- clean - Local simulation above against the exact pinned TheRock commit (`df3d451a`), not just current TheRock `main` -- default per-component walk levels, no `--level` override ## Notes Editing `therock-multi-arch-ci.yml` matches TheRock's own "run everything" fallback trigger patterns (and rocm-libraries' own), so this PR's live CI can't validate the underlying per-path selection logic on itself -- same caveat as #11785. The table above is the primary evidence. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests. Co-authored-by: Cursor <cursoragent@cursor.com>
ISSUE ID : ROCm/TheRock#3343
Motivation
The default TheRock Multi-Arch CI passes changed monorepo paths directly to TheRock's test dependency selector. Paths under
shared/, includingshared/stinkytofu, are not recognized as TheRock subprojects. This allowed shared BLAS changes to rebuild math-libs while running only sanity tests, as seen on PR #11643.The multi-arch rollout issue requires at least the test coverage selected by the existing
therock_matrix.py, but that mapping was only used by the legacy single-arch workflow.Technical Details
therock_matrix.pymapping before invoking the Linux and Windows multi-arch workflows.shared/stinkytofu,shared/tensile,shared/origami, andshared/mxdatagenerator.shared/rocrollerchanges, Origami tests forshared/origamichanges, and rocRoller tests forshared/mxdatageneratorchanges.shared/*subtree has no test mapping instead of silently producing a sanity-only green run.Test Plan
.github/scriptstest suite.Test Result
python -m pytest .github/scripts/tests/multi_arch_test_projects_test.py -q: 9 passed.python -m pytest .github/scripts/tests -q: 149 passed, 8 xfailed, 37 subtests passed.pre-commit run: passed.Device / Architecture Coverage
This changes test selection rather than product behavior. PR CI should run the full available multi-arch matrix because the workflow itself changed. TheRock currently has no gfx1250 hardware runner, so this restores the available BLAS GPU lanes but does not add native gfx1250 execution for stinkytofu.
Adjacent Tests Considered
The existing single-arch mapping is retained as the minimum coverage source of truth. Origami and mxDataGenerator also select their directly affected component tests because those are not included in the legacy BLAS umbrella.
Related
Submission Checklist
Risk level
Medium. This changes test selection for every shared BLAS subtree and intentionally increases CI coverage. Unit tests lock each mapping, unknown shared paths fail closed, and the PR workflow change triggers the full available multi-arch CI matrix.