Skip to content

ci: narrow the GPU serve matrix with a serve paths-filter + PR canary (EAI-7746) - #156

Open
fredespi wants to merge 1 commit into
mainfrom
e2e-task-9-narrow-serve-paths-filter-so-non
Open

ci: narrow the GPU serve matrix with a serve paths-filter + PR canary (EAI-7746)#156
fredespi wants to merge 1 commit into
mainfrom
e2e-task-9-narrow-serve-paths-filter-so-non

Conversation

@fredespi

Copy link
Copy Markdown
Collaborator

Summary

The changes job gated the three self-hosted GPU E2E jobs (e2e-gpu, e2e-gpu-strix-ubuntu, e2e-gpu-strix-windows) on the coarse heavy paths-filter, which trips on any **/*.rs change. So a Rust PR that can't affect serving (dashboard, unrelated crates) fired the whole real-GPU serve matrix on scarce serial hardware. This narrows that matrix and adds a fast pre-merge serve canary.

Changes

  • serve paths-filter (EAI-7746): a dedicated filter covering the serve code path (engines/**, crates/rocm-core, crates/rocm-engine-protocol, apps/rocm, apps/rocmd), the E2E harness (tests/e2e-cucumber/**, crates/e2e-report, xtask, **/*.feature), plus broad-dep safety nets (root Cargo.toml, Cargo.lock, rust-toolchain*, workflow files). Excludes the rocm-dash-* crates — they build into rocm but can't change serve behaviour, and their compile coverage stays on the always-on build/test lanes. The GPU jobs now gate on serve; forced true off-PR so the merge queue always runs the full matrix (required checks never starved).
  • merge_group gating + PR canary: the two Strix lanes run on merge_group/push only (skip on PR; required-but-continue-on-error, so the skip satisfies branch protection). The MI300X lane still runs on pull_request but in canary mode (E2E_PR_CANARY), serving only a single minimal real scenario as a pre-merge smoke; the full matrix runs in the merge queue.
  • @canary / @serves-on-gpu harness gate (mirrors @nightly): in canary mode every GPU-serving scenario except the canary resolves to Skip, so platform.json stays valid and the consolidated report reconciles. @serves-on-gpu tags the scenarios that real-serve on a GPU host without @requires-gpu (short-name expansion, chat behavioural) so they're skipped in canary mode but still mock-covered every PR.
  • report gate: the consolidated report now gates on heavy || serve so a serve-only change still produces the required E2E consolidated report check.

Test plan

  • Linux container gate green: clippy --workspace --all-targets --exclude e2e-cucumber -D warnings, workspace tests, e2e-cucumber --lib, and cargo xtask e2e mock lane (reconciliation: 3 xfail / 0 XPASS / 0 unexpected).
  • ci.yml YAML parses; serve gates exactly the 3 GPU jobs + report; heavy still gates the mock/build/test lanes.
  • On this PR: confirm every required GPU check is produced (run or green-skip), none left pending.
  • Scoped dispatch to confirm the canary path serves only the single @canary scenario.

…I-7746)

The `changes` job gated the three self-hosted GPU E2E jobs on the coarse
`heavy` filter, so any Rust change (dashboard, unrelated crates) fired the
whole real-GPU serve matrix on scarce serial hardware.

- Add a dedicated `serve` paths-filter (serve code path + engines + E2E
  harness + broad-dep safety nets; excludes the rocm-dash crates) and gate
  the GPU jobs on it, so non-serve Rust PRs skip the matrix. Forced true
  off-PR so the merge queue always runs the full matrix.
- Gate the two Strix lanes to merge_group/push only; keep the MI300X lane
  on pull_request in canary mode (E2E_PR_CANARY) running a single minimal
  real serve as a pre-merge smoke.
- Add a `@canary` / `@serves-on-gpu` harness gate (mirrors `@nightly`): in
  canary mode every GPU-serving scenario except the canary resolves to Skip,
  keeping platform.json valid so the consolidated report reconciles.
- Gate the consolidated report on `heavy || serve` so a serve-only change
  still produces it.

Signed-off-by: fredespi <fredrik.espinoza@gmail.com>
@fredespi
fredespi requested a review from a team as a code owner July 31, 2026 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant