[CI] CI: add extended test workflow

[gyohuangxin]

No description provided.

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

• ✅ Pre-checks (submodule verification, code formatting)
• ✅ Aiter op tests (gfx942 + gfx950)
• ✅ Triton tests on MI35X (only when aiter/ops/triton/** or related paths are changed)

Extended tests (opt-in via labels):

Label	Tests
ci:triton-300x	Run an additional Triton test job on MI300X in PRs; main branch always runs both MI35X and MI300X
ci:sglang	SGLang integration tests: DeepSeek-R1-MXFP4 accuracy, Qwen 3.5 accuracy
ci:atom	ATOM benchmark: DeepSeek-R1-0528, GPT-OSS-120B
ci:atom_full	ATOM accuracy suite for PR and main models from ATOM models_accuracy.json
ci:vllm	vLLM benchmark: GPT-OSS-120B, DeepSeek-R1-0528, Kimi-K2.5
ci:all	All standard extended tests (excludes ci:atom_full)

Only add ci:atom_full for FlyDSL or Triton upgrades.
Add labels via the sidebar or gh pr edit 4458 --add-label <label>

[Copilot]

Pull request overview

Adds a new GitHub Actions workflow to optionally trigger and gate PRs on an external “extended test” run, based on PR title or an explicit label, and then wait for a specific commit status context to report success/failure.

Changes:

• Introduces .github/workflows/extended-test.yaml using pull_request_target with same-repo-only gating.
• Builds and sends a repository_dispatch payload (PR metadata + source run info) to a configured target repository.
• Polls the commit status context extended-tests/aiter until success/failure or a timeout.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

.github/workflows/extended-test.yaml:7

• To match the repository’s existing pull_request_target workflows and avoid dispatching extended tests for PRs targeting non-main branches, add a branches: [main] filter under pull_request_target (see .github/workflows/pr-title-tags.yaml and pr-welcome-comment.yaml).

on:
  pull_request_target:
    types: [opened, synchronize, reopened, ready_for_review, edited, labeled]

.github/workflows/extended-test.yaml:67

• GITHUB_TRIGGERING_ACTOR is not guaranteed to be present in the runner environment for this event; using it with os.environ[...] can raise KeyError and fail the workflow. Prefer a safe fallback to GITHUB_ACTOR (always set) to keep dispatch payload generation reliable.

                  "triggering_actor": os.environ["GITHUB_TRIGGERING_ACTOR"],

[leo-automation]

Thanks, this looks good overall. I noticed two small things we may want to adjust:

1. The workflow currently includes the architecture name in the public title-matching condition. Could we make the test label-only and remove those title checks?
2. Since edited is included in the event types, changing the PR title or description while the label is present can restart the test. Could we remove edited, since the label and new commits already provide the triggers we need?

[Copilot]

🔵 Needs a closer look

The new workflow has branch/draft scoping and a paginated-status polling issue that can cause unintended runs or timeouts.

Review details

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

.github/workflows/extended-test.yaml:8

• pull_request_target trigger is not scoped to the default branch. Other pull_request_target workflows in this repo restrict to branches: [main], which avoids running this secret-using workflow on PRs targeting release/feature branches unintentionally.
  .github/workflows/extended-test.yaml:31
• This workflow can dispatch extended tests for draft PRs (e.g., on opened/synchronize) if the title matches. Most other PR-triggered CI workflows in this repo gate on pull_request.draft == false, and ready_for_review is already included in the event types.
  .github/workflows/extended-test.yaml:121
• The commit-statuses endpoint is paginated; fetching only the first 100 statuses can miss the desired context if there are many statuses on the commit (e.g., repeated CI runs). That can cause this workflow to wait until timeout even though the status exists.

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite