CI: Cancel stale CUDA and ROCm workflow runs

[Gasoonjia]

Fixes #22845.

CUDA, CUDA Windows, and ROCm workflows currently keep older runs active when a pull request is updated. This enables concurrency cancellation for those workflows, consistent with the other ExecuTorch CI workflows using the same concurrency group.

Authored with Codex.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22847

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Pending, 1 Unclassified Failure

As of commit ca3b92c with merge base f5e1369 ():

UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:

• Test CUDA Builds / test-model-cuda-e2e-Qwen3.5-35B-A3B-HQQ-INT4-quantized-int4-tile-packed / linux-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 1

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[huydhn]

@claude Do we need to rewrite the concurrency group like pull or trunk workflows here too

[claude]

Claude finished @huydhn's task in 1m 24s —— View job

---

Answer

No — you don't need to rewrite the concurrency group. The group: expression in cuda.yml, rocm.yml, and cuda-windows.yml is already byte-for-byte identical to trunk.yml:

group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref_name }}-${{ github.ref_type == 'branch' && github.sha }}-${{ github.event_name == 'workflow_dispatch' }}-${{ github.event_name == 'schedule' }}

This PR only flips cancel-in-progress: false → true, which makes these three workflows behave exactly like trunk.yml (which already ships cancel-in-progress: true with this same group). So the change is already consistent with trunk.

Why the group is fine as-is (and why it differs from pull.yml):

pull.yml uses a slightly different key:

group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}-${{ github.event_name == 'workflow_dispatch' && github.run_id }}-${{ github.event_name == 'schedule' }}

The two meaningful differences are intentional and appropriate for accelerator/trunk-style workflows:

1. Push fallback: github.ref_name + github.sha (trunk-style) vs. just github.sha (pull). Because the trunk-style group folds ${{ github.ref_type == 'branch' && github.sha }} in, each push commit to main gets a unique group and post-merge runs are not canceled by the next push — which is what you want for CUDA/ROCm coverage on trunk. Adopting the pull.yml form would key pushes purely on branch and risk canceling in-progress main runs.

2. workflow_dispatch key: pull.yml appends && github.run_id so each manual dispatch is its own group; trunk (and these workflows) don't. This is a pre-existing trunk convention — two concurrent manual dispatches would share a group. Only worth changing if you specifically want manual accelerator runs to never cancel each other, but that would diverge from trunk.yml.

Recommendation: Keep the group as-is. Matching trunk.yml is the right call here since CUDA/CUDA-Windows/ROCm run on both PRs and pushes to main, just like trunk. Rewriting to the pull.yml shape would actually change push-event behavior for the worse.

_{· branch fix/cancel-stale-accelerator-ci}