[nirvedhmeshram]

Problem

When a PR is merged or closed, its in-flight Iris Tests, performance-regression and external-validation runs keep going and hold the GPU runners. The concurrency group only cancels a run when a newer run of the same PR starts, and merging or closing starts none.

A live example: #570 is merged, but its Iris Tests run (from commit 8f34e8a9) is still queued.

Change

New cancel-closed-pr-ci.yml runs every 10 minutes (and on manual dispatch). It lists in-flight pull_request runs and cancels any whose PR is closed.

• Finding the PR: each run's PR is found by head branch and commit, because fork runs carry no PR number. A run is cancelled only if every PR whose head is that commit is closed.
• Security: PR-supplied text like branch names is only ever data: URL-encoded for the API query and compared, never evaluated.

GPU workflows' concurrency is keyed on the PR number instead of github.head_ref, the same pattern IREE uses. Two PRs from different forks with the same branch name (e.g. patch-1) currently share a group and cancel each other's runs.

Why a scheduled sweep

Approach	Merged PRs	Fork contributors needing approval	Security scan
pull_request: closed + concurrency (first commit)	❌ on merge GITHUB_REF is refs/heads/main (docs), so cancel-in-progress is false	❌ the close run waits for approval too	✅
pull_request_target: closed + API (second commit)	✅	✅ always runs	❌ HIGH dangerous-triggers
Scheduled sweep + API (this)	✅	✅	✅

The cost is up to one interval (about 10 minutes) before a closed PR's runs stop, against GPU runs that take 1–2 hours. If instant cancellation is worth a reviewed dangerous-triggers exception in .github/scan_tools_configs/zizmor.yml, the second commit's workflow can come back.

Testing

• Dry run on live data: I ran the sweep script against ROCm/iris's live runs with the cancel call stubbed out. It picked exactly one run, Run GPU CI on the linux-mi350-8gpu-iris runner label #570's still-queued Iris Tests, and left every open PR's runs alone (this one, Allocate CI GPUs per task instead of per job #571, Dependabot, Copilot).
• Security scan: zizmor 1.30.0 --persona regular with the repo's config reports no findings.

Scheduled workflows only run from main, so this takes effect after merge; it can also be triggered from the Actions tab.

🤖 Generated with Claude Code

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

Review effort: Lite
Findings: None

What changed in this PR

Updates GPU-related GitHub Actions workflows so CI runs don’t keep occupying GPU runners after a PR is closed/merged, by improving concurrency grouping and adding explicit run cancellation on PR close.

Changes:

• Key concurrency groups by PR number (instead of head_ref) to prevent cross-fork branch-name collisions.
• Add a pull_request_target: closed workflow that cancels queued/running workflow runs for the PR’s head SHA via the Actions API.

File	Description
.github/​workflows/​iris-tests.yml	Switch concurrency grouping to PR number to avoid fork branch collisions.
.github/​workflows/​iris-performance-regression-test.yml	Switch concurrency grouping to PR number to avoid fork branch collisions.
.github/​workflows/​iris-external-validation-test.yml	Switch concurrency grouping to PR number to avoid fork branch collisions.
.github/​workflows/​cancel-closed-pr-ci.yml	New workflow to cancel in-flight PR runs when the PR is closed.

---

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

[nirvedhmeshram]

This seems too much complexity for a small problem so I will close this PR