feat(ci): Add build_stages input to filter CI build graph

[raramakr]

Add a build_stages allowlist input to setup_multi_arch.yml that lets
callers specify which stages to build. Stages outside the allowlist
are skipped entirely (no build, no artifact copy). This enables
focused CI runs that only build specific pipeline stages.

• Add build_stages input to setup_multi_arch.yml
• Add skip_stages input to multi_arch_build_portable_linux.yml and multi_arch_build_windows.yml
• Add _resolve_skipped_stages() to convert allowlist to skip list
• Pass skip_stages through multi_arch_ci_{linux,windows}.yml

ISSUE ID: #7202

[therock-pr-bot]

✅ All Checks Passed — Ready for Review

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	—
🔎 pre-commit	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—
🤖 therock-pr-bot	✅ Pass	—

🎉 All checks passed! This PR is ready for review.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

[therock-pr-bot]

🎉 All checks passed! This PR is ready for review.

[ScottTodd]

skip_stages on its own LGTM, I don't think the validate_artifact_structure change should be needed though.

BTW, I added similar "skip arbitrary stages" to another CI system before, see https://iree.dev/developers/general/contributing/#ci-behavior-manipulation and the code like if: contains(fromJson(needs.setup.outputs.enabled-jobs), 'test_android') in https://github.com/iree-org/iree/blob/main/.github/workflows/pkgci.yml

[geomin12]

the whole purpose of multi-arch is to re-use or re-build all of ROCm, so we can make sure downstream packaging (pytorch, python packages, tarball packaging) is not impact (so release packages don't break). if we skip, we won't be able to test downstream packages

i did exact work here: #6709 but aligned with team to understand the purpose of multi-arch and its importance

[raramakr]

the whole purpose of multi-arch is to re-use or re-build all of ROCm, so we can make sure downstream packaging (pytorch, python packages, tarball packaging) is not impact (so release packages don't break). if we skip, we won't be able to test downstream packages

i did exact work here: #6709 but aligned with team to understand the purpose of multi-arch and its importance

Thanks for the context on multi-arch's purpose. I agree that for release builds and others we need the full pipeline to validate downstream packaging.

The build_stages input is intended for specialized CI configurations, not to replace the default multi-arch flow. The primary use case is #7202: host-asan
asan-presubmit builds from rocm-systems only need compiler-runtime and runtime-tests

This allows callers to create focused ASAN presubmit workflows that:

• Build only the two required stages
• Run on every PR to catch memory errors early
• Stay cost-effective by skipping unrelated stages

The default behavior remains unchanged — callers that don't set build_stages still get the full multi-arch pipeline.

[ScottTodd]

the whole purpose of multi-arch is to re-use or re-build all of ROCm, so we can make sure downstream packaging (pytorch, python packages, tarball packaging) is not impact (so release packages don't break). if we skip, we won't be able to test downstream packages

We want both:

• the ability to build/test all of rocm, including frameworks like jax and torch
• the ability to build/test only a subset, e.g. media-libs, debug-tools

choosing between those will be "defcon" levels documented at https://github.com/ROCm/TheRock/blob/main/docs/rfcs/RFC0013-Consumer-Based-Test-Selection.md#background-gating-levels

see also the diagrams I posted originally at #3343 (comment)

in particular, case 3 looks like it could benefit from skipping entire build stages

• change just rocGDB
• use prebuilt artifacts for the compiler
• decide to limit testing to just debug-tools, don't opt-in to package builds and tests