Repository navigation
fix(ci): pull rocm-libraries DVC data on external rocm-systems builds - #9544
Conversation
--dvc-projects replaces fetch_sources.py's default project list rather than extending it, so the rocm-systems entry listing only "external-rocm-systems" dropped rocm-libraries entirely. pull_large_files() never visited <therock-root>/rocm-libraries, leaving the 24 DVC-tracked rocSPARSE SuiteSparse test matrices unmaterialized and failing the math-libs stage at ClientMatrices.cmake with a configure FATAL_ERROR. hipSPARSE breaks via the same path and is covered by the same fix. This mirrors the bug #8204 fixed in the other direction, so the comment explaining the replace-not-extend semantics is repeated here. Fixes #9537 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.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. |
| "dvc_projects": ["external-rocm-systems"], | ||
| # --dvc-projects replaces fetch_sources.py's default project list rather | ||
| # than extending it, so "rocm-libraries" is listed explicitly to pull the | ||
| # rocSPARSE/hipSPARSE test matrices ClientMatrices.cmake needs. | ||
| "dvc_projects": ["external-rocm-systems", "rocm-libraries"], |
There was a problem hiding this comment.
Ok if this works to unblock for now, but I'm not sure why we have this "replace the default project list for an external repo" setup in this way. We should be fetching
- rocm-systems DVC files together with the rocm-systems submodule
- rocm-libraries DVC files together with the rocm-libraries submodule
Here the config is "rocm-systems" but it now always will fetch rocm-libraries DVC files, even if the build stage is not doing anything with rocm-libraries. I believe we've had the same issue on the other side where rocm-libraries always fetches rocm-systems DVC files for all build stages.
We can also scope which DVC files are fetched based on which subprojects are being built by a particular stage as part of a sparse checkout, which will be especially useful when truly large files (e.g. tensile config files) move into DVC.
See https://github.com/ROCm/rocm-systems/actions/runs/40588237180/job/122486562625?pr=14418 for example, where Windows files and other files unrelated to the emulation build stage are fetched:
dvc config detected in /__w/rocm-systems/rocm-systems/external-rocm-systems, fetching large files
pull: 38 pointer file(s) from s3://therock-dvc/rocm-systems
fetching amd_comgr_2.dll (109.9 MiB)
fetching amdhip64_6.dll (17.9 MiB)
...
There was a problem hiding this comment.
agree, this hasn't been touched in months.... those scoping of dvc calls will definitely help with resources but i'll land this once math libs in the test PR pass and work on scoping as a follow-up
## Motivation CI is failing on ROCm/rocm-libraries#14471 and ROCm/rocm-systems#14369 when using the latest CI code from this repository on the release branch. These cherry-picks fix two issues: * #9547 to fix MSI build failures observed on ROCm/rocm-libraries#14471 * #9544 to fix DVC fetch failures #9537 ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/TheRock/blob/main/CONTRIBUTING.md. --------- Co-authored-by: Ian Dass <145489691+idass1990@users.noreply.github.com> Co-authored-by: Geo Min <geomin12@amd.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
--dvc-projects replaces fetch_sources.py's default project list rather than extending it, so the rocm-systems entry listing only "external-rocm-systems" dropped rocm-libraries entirely. pull_large_files() never visited /rocm-libraries, leaving the 24 DVC-tracked rocSPARSE SuiteSparse test matrices unmaterialized and failing the math-libs stage at ClientMatrices.cmake with a configure FATAL_ERROR. hipSPARSE breaks via the same path and is covered by the same fix.
This mirrors the bug #8204 fixed in the other direction, so the comment explaining the replace-not-extend semantics is repeated here.
Running a test here: ROCm/rocm-systems#14418, rocsparse passed!
Fixes #9537
After this lands, I'll bump hashes for rocm-libraries + rocm-systems