You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[CI] Optimize CI workflow job selection across repositories #8708
This issue tracks job selection optimizations we can make to the CI system such that workflow runs include enough relevant build and test jobs without overusing machine resources that are in limited supply and expensive to operate.
High level design goals
Automatic job selection may produce false positives, skipping jobs that are impacted. Explicit opt-in labels can help with this, as can more exhaustive scheduled runs that do not limit the jobs run.
Changes that cannot possibly affect components should not run the builds or tests for those components, reusing cached build outputs as needed or skipping jobs entirely
Metrics and implementation complexity can help drive prioritization between each optimization strategy
Looking across the subissues here, I think we can scale implementation and testing of changes to this part of the CI system more effectively through some changes to the code architecture and testing strategy. Take ROCm/rocm-libraries#11439 (comment) for example, where 10+ pull requests were created just to test that commits like ROCm/rocm-libraries@7a05c67 triggered the expected jobs.
From 7a05c6743884c0b049ec73e620ab9bd675245125 Mon Sep 17 00:00:00 2001
From: Joseph Macaranas <joseph.macaranas@amd.com>
Date: Sat, 29 Aug 2026 00:23:05 -0400
Subject: [PATCH] test(ci): validate rocRoller multi-arch detection
---
shared/rocroller/CMakeLists.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/shared/rocroller/CMakeLists.txt b/shared/rocroller/CMakeLists.txt
index 1271821962b2..d87d08649396 100644
--- a/shared/rocroller/CMakeLists.txt+++ b/shared/rocroller/CMakeLists.txt@@ -1,6 +1,7 @@
# Copyright Advanced Micro Devices, Inc., or its affiliates.
# SPDX-License-Identifier: MIT
+# Temporary no-op change to validate TheRock multi-arch CI project detection.
cmake_minimum_required(VERSION 3.25.2)
set(ROCROLLER_VERSION 1.0.0)
set(ROCROLLER_SOVERSION 1)
(aside: #8691 should be able to detect that commit as a no-op and skip CI for it)
What I'm imagining is
Add a directory full of testdata patch files and then some test harness code in python or with supplemental data files that checks "for this commit patch, which build/test jobs would be triggered for the pull_request event?"
CLI scripts that can be pointed at commits or pull requests to ask "what would the current CI code decide to do for this?"
CLI scripts or agent skills that can turn commits or pull requests into test cases (especially as regression tests)
Requesting the patch file for a PR via the API should be fast and hopefully avoids needing to git fetch commit ranges (as we've started doing more, cc @erman-gurses and @geomin12 )
"configure external repo ci" can still be folded into "configure ci" (as mentioned elsewhere) to make this apply evenly across PRs to TheRock and component submodules
Activity
ScottTodd commentedon Oct 5, 2026
Looking across the subissues here, I think we can scale implementation and testing of changes to this part of the CI system more effectively through some changes to the code architecture and testing strategy. Take ROCm/rocm-libraries#11439 (comment) for example, where 10+ pull requests were created just to test that commits like ROCm/rocm-libraries@7a05c67 triggered the expected jobs.
We could add test cases using git patch files like https://github.com/ROCm/rocm-libraries/pull/11468.patch (or https://github.com/ROCm/rocm-libraries/commit/7a05c6743884c0b049ec73e620ab9bd675245125.patch) for that PR/commit from @jayhawk-commits :
(aside: #8691 should be able to detect that commit as a no-op and skip CI for it)
What I'm imagining is