Multi-arch CI support - #179
Closed
lumachad wants to merge 12 commits into
Closed
Conversation
lumachad
added
ci:skip
lumachad
added
ci:multi-arch
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
June 19, 2026 12:22
3bcb1e2 to
f1144ea
Compare
lumachad
added
ci:multi-arch
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
June 19, 2026 17:50
f1144ea to
f235da4
Compare
lumachad
added
ci:multi-arch
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
June 19, 2026 18:56
f235da4 to
21c9ee7
Compare
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
June 19, 2026 19:10
21c9ee7 to
703a4e6
Compare
lumachad
added
ci:multi-arch
lumachad
added
ci:multi-arch
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
June 22, 2026 07:54
7dce425 to
8cbf48d
Compare
lumachad
added
ci:multi-arch
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
June 22, 2026 07:58
8cbf48d to
d9bc630
Compare
lumachad
added
ci:multi-arch
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
July 10, 2026 11:24
d9bc630 to
09c6003
Compare
lumachad
added
ci:multi-arch
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
July 10, 2026 12:15
09c6003 to
0271125
Compare
lumachad
added
ci:multi-arch
lumachad
force-pushed
the
users/lumachad/amd-staging/multi-arch
branch
from
July 10, 2026 15:29
0271125 to
16c55c8
Compare
lumachad
added
ci:multi-arch
Add three GitHub Actions workflows mirroring the rocm-systems multi-arch CI setup alongside the existing single-arch therock-ci.yml: - therock-multi-arch-ci.yml: manual (workflow_dispatch) trigger for on-demand release builds across gfx94X and gfx950. Uses TheRock's setup_multi_arch / multi_arch_ci_linux reusable workflows at @main and passes external_repo so TheRock pulls in the rocgdb source under test. - therock-multi-arch-ci-nightly.yml: cron (07:00 UTC) that dispatches therock-multi-arch-ci.yml on amd-staging with gfx94X,gfx950. Uses workflow_dispatch rather than schedule so TheRock honours the specified GPU family list. - therock-multi-arch-ci-asan.yml: fires on push to amd-staging / amd-staging-rocgdb-* and on workflow_dispatch. Uses build_variant host-asan and the same pinned TheRock commit as the single-arch workflows (2d417fa, 2026-06-18). Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com>
Allow each multi-arch workflow to be triggered from a pull request by applying the corresponding label: ci:multi-arch -> therock-multi-arch-ci.yml ci:multi-arch-asan -> therock-multi-arch-ci-asan.yml ci:multi-arch-nightly -> therock-multi-arch-ci-nightly.yml Each workflow gains a pull_request trigger (types: [labeled]). The guard lives on the setup job so that downstream jobs are skipped automatically via the needs: chain when the label is absent. For the nightly trigger, the dispatched ref uses github.head_ref when invoked from a PR so therock-multi-arch-ci.yml runs against the PR branch rather than amd-staging. Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com>
ROCgdb requires -DTHEROCK_USE_EXTERNAL_ROCGDB=ON alongside -DTHEROCK_ROCGDB_SOURCE_DIR to build from an external source directory. Pass this flag via the extra_cmake_options field in the external_repo JSON so TheRock's build workflows pick it up without needing to hardcode ROCgdb-specific knowledge on the TheRock side. Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com>
Disable push/pull_request triggers on therock-ci.yml while testing the multi-arch CI pipeline (therock-multi-arch-ci.yml). Keep workflow_dispatch so it can still be triggered manually if needed. Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com>
Switch all multi-arch CI workflows from the pinned feature branch SHA (users/lumachad/rocgdb/multi-arch-ci) to ROCm/TheRock@main, which has ROCm/TheRock#7234 (dynamic stage determination for external repos). Remove skip_packaging from the external_repo JSON; it was only available on the feature branch and is no longer needed. Add actions: read to the top-level permissions and to the setup job, required by the stage reuse feature introduced in TheRock#7234. Co-Authored-By: Claude <noreply@anthropic.com>
Enable stage_reuse_mode: "reuse-stage" in both multi-arch CI workflows (release and ASAN). TheRock's configure script will now automatically determine that rocgdb only affects the debug-tools stage and reuse all other stages (math-libs, comm-libs, storage-libs, wsl-rocdxg, etc.) from a recent TheRock baseline run, avoiding redundant builds. Default linux_test_labels to "test:rocgdb" so only rocgdb tests run during the testing phase. The default can be overridden via workflow_dispatch inputs. Co-Authored-By: Claude <noreply@anthropic.com>
Replace the two-level dispatch approach (a nightly trigger job that called benc-uk/workflow-dispatch to re-invoke therock-multi-arch-ci.yml) with a self-contained workflow that calls TheRock's reusable workflows directly, mirroring how rocm-libraries structures its nightly. The new workflow: - Drops the benc-uk/workflow-dispatch dependency - Adds workflow_dispatch for on-demand manual runs - Hardcodes gfx94X,gfx950 and test:rocgdb (no inputs needed; use therock-multi-arch-ci.yml for custom on-demand runs) - Enables stage_reuse_mode: "reuse-stage" and actions: read, consistent with the other multi-arch workflows Co-Authored-By: Claude <noreply@anthropic.com>
The setup_multi_arch job re-exports the checked-out TheRock commit as needs.setup.outputs.ref. Use that output in the linux_build_and_test and multi_arch_ci_summary jobs instead of repeating the hardcoded SHA, so a ref bump only needs to touch the two mandatory uses: literals per file rather than every occurrence. Co-Authored-By: Claude <noreply@anthropic.com>
Rework the reporting block in run_update() so dry runs always spell out both tracked values explicitly: - Print both TheRock ref and build container digest on every run, labelling each as "update" (old -> new) or "unchanged (current)". - When nothing has changed, print an explicit "No updates" message instead of silently exiting. - When dry-run mode would make changes, name exactly which values would be updated. Co-Authored-By: Claude <noreply@anthropic.com>
Move THEROCK_COMMIT_REF and the build container digest out of therock-ci-linux.yml and into a new plain data file, .github/therock-deps.json. This lets the automated update workflow push changes with only contents: write on the GITHUB_TOKEN; the workflows: permission that the default token cannot hold is no longer needed. Changes: - Add .github/therock-deps.json with therock_commit_ref, build_image, and their respective date fields. - Add a resolve job to therock-ci-linux.yml that reads and validates the JSON file and exposes both values as job outputs. The build job gains needs: resolve and references the outputs for container.image and THEROCK_COMMIT_REF. - Rewrite update_therock_deps.py to update therock-deps.json instead of therock-ci-linux.yml, dropping render_ci_linux/read_current and the CI_LINUX path constant. Co-Authored-By: Claude <noreply@anthropic.com>
Extend update_therock_deps.py to also find usable TheRock CI baseline runs for the multi-arch workflows. For each build variant (release and ASAN), the script walks recent successful TheRock main CI runs and picks the newest one whose artifacts cover the required prebuilt stages (runtime-tests, wsl-rocdxg, math-libs, comm-libs, storage-libs, dctools-core, profiler-apps, cv-libs, media-libs) for the required GPU families (gfx94X, gfx950). Two independent baseline run IDs are maintained in configs.json: therock_baseline_run_id / therock_baseline_run_ref release therock_baseline_run_id_asan / therock_baseline_run_ref_asan ASAN The ASAN nightly runs infrequently, so its ref may lag the release ref by days; when no fresh ASAN baseline is found the existing ASAN fields are preserved. Enable the 6-hour schedule on therock-deps-update.yml so the baseline run IDs stay fresh automatically. Co-Authored-By: Claude <noreply@anthropic.com>
Add a resolve job to all three multi-arch CI workflows that reads .github/configs.json and emits the TheRock ref, baseline run ID, and prebuilt stages list as job outputs. The resolve step validates that therock_commit_ref is a valid SHA-40 and therock_baseline_run_id (when present) is a numeric run ID, failing the job immediately on bad data. When a baseline run ID is available, prebuilt_stages is set to all stages rocgdb does not affect (runtime-tests, wsl-rocdxg, math-libs, comm-libs, storage-libs, dctools-core, profiler-apps, cv-libs, media-libs), so only compiler-runtime and debug-tools are rebuilt. When absent (configs.json not yet populated), prebuilt_stages is empty and all stages build normally. The ASAN workflow uses its own paired ref (therock_baseline_run_ref_asan) so the ASAN build is always pinned to the same TheRock commit as the ASAN baseline artifacts. workflow_dispatch inputs for prebuilt_stages and baseline_run_id still override configs.json for manual testing. Co-Authored-By: Claude <noreply@anthropic.com>
Collaborator
Author
|
Dropping. 3rd time's the charm: #295 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Enable multi-arch CI support for ROCgdb