fix(ci): stop no-op label events from cancelling PR deployments

[Michael Flanakin (flanakin)]

🛠️ Description

The PR Deploy workflow shared one concurrency group across both its pull_request and pull_request_target triggers, with cancel-in-progress: true:

group: ftk-pr-${{ github.event.pull_request.number }}

Any bot label landing while a test deployment was running entered that same group and cancelled the deployment. The label run then skipped every job, because check-options requires github.event.label.name == 'Needs: Deployment'.

Observed on #2291: a pull_request edit started deploy run 34090567648 at 06:22:51; a bot label started pull_request_target run 34090602148 28 seconds later and killed it. The PR was left showing cancelled/skipped deploy jobs, which reads as "deployment not requested" rather than "deployment was killed".

Fix: label events that are not Needs: Deployment get a unique, throwaway group, so they cancel nothing. Real deployments stay in the shared per-PR group.

Event	Group	Effect
pull_request (opened/synchronize/edited)	ftk-pr-<n>	synchronize cancels the prior deployment ✅
pull_request_target, label = Needs: Deployment	ftk-pr-<n>	shares the group — a later push still cancels it ✅
pull_request_target, any other label	ftk-pr-<n>-noop-<run_id>	unique per run, cancels nothing ✅

Suffixing the group with github.event_name was rejected as the fix: it would split all pull_request_target runs off, so a new push would no longer cancel an in-flight fork deployment and two labels could stack concurrent deployments.

Verified: the workflow YAML parses (the Needs: Deployment literal requires the group value to be quoted), all 7 jobs are intact, and no other workflow uses a ftk-pr-* concurrency group.

Fixes #

📋 Checklist

🔬 How did you test this change?

• 🤏 Lint tests
• 🤞 PS -WhatIf / az validate
• 👍 Manually deployed + verified
• 💪 Unit tests
• 🙌 Integration tests

📦 Deploy to test?

• Hubs + ADX (managed)
• Hubs + Fabric (manual) — URI:
• Hubs (manual)
• Hubs (no data)
• Workbooks
• Alerts

🙋‍♀️ Do any of the following that apply?

• 🚨 This is a breaking change.
• 🤏 The change is less than 20 lines of code.

📑 Did you update docs/changelog.md?

• ✅ Updated changelog (required for dev PRs)
• ➡️ Will add log in a future PR (feature branch PRs only)
• ❎ Log not needed (small/internal change)

📖 Did you update documentation?

• ✅ Public docs in docs (required for dev)
• ✅ Public docs in docs-mslearn (required for dev)
• ✅ Internal dev docs in docs-wiki (required for dev)
• ✅ Internal dev docs in src (required for dev)
• ➡️ Will add docs in a future PR (feature branch PRs only)
• ❎ Docs not needed (small/internal change)

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The change is small, well-scoped to the workflow’s concurrency group, and matches the stated behavior for label-triggered no-op runs without affecting real deployment cancellation semantics.

Pull request overview

Updates the PR Deploy GitHub Actions workflow concurrency configuration so that label events which do not request deployment no longer cancel in-flight PR deployments, while preserving the desired “new push cancels prior deployment” behavior for real deployments.

Changes:

• Adds explanatory comments documenting why PR deploy runs share a concurrency group and why non-deploy label events must not.
• Adjusts concurrency.group so non-Needs: Deployment pull_request_target label events use a unique, per-run “noop” group (preventing cancellation of active deployments).

File summaries

File	Description
.github/workflows/ftk-pr-deploy.yml	Refines the concurrency group expression to isolate no-op label-triggered runs so they can’t cancel real PR deployment runs.

Review details

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

---

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