CI: Enable multi-GPU tests via label on PRs

[gyohuangxin]

Summary

• Multi-GPU op tests now support on-demand triggering on PRs via ci:multi-gpu or ci:all labels
• Previously multi-GPU tests only ran on push to main
• Updated PR welcome comment to include ci:multi-gpu in the label table

Test plan

• Open a PR without labels → verify multi-GPU tests are skipped
• Add ci:multi-gpu label → verify multi-GPU tests trigger
• Add ci:all label → verify multi-GPU tests trigger along with other extended tests
• Push to main → verify multi-GPU tests still run as before

🤖 Generated with Claude Code

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

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

Extended tests (opt-in via labels):

Label	Tests
ci:sglang	SGLang integration tests
ci:atom	ATOM benchmark (DeepSeek-R1 + GPT-OSS)
ci:multi-gpu	Multi-GPU op tests (8 GPU)
ci:vllm	vLLM benchmark
ci:all	All of the above

Add labels via the sidebar or gh pr edit 2203 --add-label <label>

[Copilot]

Pull request overview

This PR enables Multi-GPU op tests to be triggered on-demand from pull requests via the ci:multi-gpu (or ci:all) label, in addition to their existing automatic execution on pushes to main. The PR also updates the welcome comment posted on new PRs to document this new label.

Changes:

• Added labeled to the pull_request event types and updated the multi-gpu job's if condition to run on PRs with the ci:multi-gpu or ci:all label
• Updated the PR welcome comment to include the ci:multi-gpu label in the opt-in label table

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/aiter-test.yaml	Adds labeled to PR trigger types; replaces github.ref == 'refs/heads/main' guard on multi-gpu job with a label-aware condition
.github/workflows/pr-welcome-comment.yaml	Adds ci:multi-gpu row to the label reference table in the welcome comment

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Adding labeled to the pull_request trigger types introduces two related operational issues:

1. Unnecessary re-runs of standard jobs: The check-signal, build_aiter_image, split_aiter_tests, and standard jobs have if conditions that only guard against draft PRs, so they will all re-run whenever any label is added to a PR — not just ci:multi-gpu or ci:all. This wastes GPU resources.

2. Cancellation of in-flight runs: Because cancel-in-progress is true for non-main branches and the concurrency group is keyed solely on github.workflow-github.ref, applying the ci:multi-gpu label while the standard test suite is already running will cancel that in-progress run, causing developers to lose intermediate results.

A cleaner approach would be to move the multi-gpu job into a dedicated workflow file triggered only by the labeled event (and push to main), which is the pattern used by the other opt-in workflows (atom-test.yaml, sglang_downstream.yaml, vllm_benchmark.yaml). Alternatively, the if conditions on all non-multi-gpu jobs could be extended to also skip execution when github.event.action == 'labeled'.

[Copilot]

The new if condition github.event_name != 'pull_request' is broader than the original github.ref == 'refs/heads/main'. In addition to push events on main, it also enables multi-gpu to run on workflow_dispatch events triggered from any branch (including feature branches), whereas the old condition restricted execution to pushes to main. This behavior change may be intentional, but it is worth verifying — if the intent is to only run on push to main and on labeled PRs, the non-PR branch of the condition should be changed to github.event_name == 'push' (which still covers both push to main and allows label-triggered PRs to work).

Suggested change

	github.event_name != 'pull_request' ||
	github.event_name == 'push' ||