Skip to content

[CI] Optimize CI workflow job selection across repositories #8708

Open
2 of 7 issues completed
Open

Description

@ScottTodd

Background

TheRock's "multi-arch CI" is now in use across https://github.com/ROCm/rocm-libraries/ and https://github.com/ROCm/rocm-systems/ (see #3343). It is also used (or will soon be used) for several build variants: 'release', 'asan', 'tsan', 'feature flags', 'debug'.

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

Activity

  1. added
    CICDRelated to CI/CD Infra
    ci-improvementImprovements to CI infra: targeted builds, artifact reuse, workflow optimization, etc.
    on Oct 2, 2026
  2. pinned this issue on Oct 2, 2026
  3. ScottTodd commented on Oct 5, 2026

    @ScottTodd
    MemberAuthor

    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 :

    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)
    • The existing path filtering code (https://github.com/ROCm/TheRock/blob/main/build_tools/github_actions/configure_ci_path_filters.py) would have adapters to patch files as one way to get a list of modified files
    • 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CICDRelated to CI/CD Infraci-improvementImprovements to CI infra: targeted builds, artifact reuse, workflow optimization, etc.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions