ci: scope labeler concurrency group to the PR

[dvdksn]

Problem

The labeler workflow has been silently skipping labels on some PRs. The runs show up as cancelled rather than success.

Root cause is the concurrency config:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

The workflow triggers on pull_request_target, and for that event github.ref resolves to the base branch (refs/heads/main), not the PR head ref. So every labeler run across all open PRs lands in the same concurrency group (labeler-refs/heads/main), and cancel-in-progress: true kills whichever run is in flight as soon as another PR triggers the workflow.

When several PRs are created or updated within seconds of each other, the earlier runs get cancelled before they finish labeling. Example from recent runs:

• sbx-policy-recipes (cancelled) ← cancelled by remove-api-header (success) seconds later
• sbx-linux-keychain (cancelled) ← cancelled by storage-drivers (success) seconds later

Fix

Key the concurrency group on the PR number instead, falling back to github.ref for non-PR contexts, so each PR gets its own group and runs no longer cancel each other.

group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}

Note

A separate, rarer class of labeler failures (genuine failure status) was caused by transient GitHub infrastructure errors downloading the pinned action tarball at the "Set up job" step. Those are not addressed here as they only need a re-run.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	ba31bc5
🔍 Latest deploy log	https://app.netlify.com/projects/docsdocker/deploys/6a1eb4ba00b5850008022739
😎 Deploy Preview	https://deploy-preview-25236--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[docker-agent]

Assessment: 🟢 APPROVE

The concurrency group fix is correct. Keying on github.event.pull_request.number (with || github.ref fallback) properly isolates each PR's labeler run, so cancel-in-progress: true only cancels a stale run for the same PR rather than for any open PR.

[thaJeztah]

I see in other repositories, we just use;

group: ${{ github.workflow }}-${{ github.event.pull_request.number }}

maybe the github.ref is redundant? (combined with the cancel-in-progress`)?

[dvdksn]

very possible 🤷 😅

[thaJeztah]

Yeah, perhaps would be good to use the same; I also see a zizmor comment (but not sure if we still need that one; the comment itself could be useful for context though);

  pull_request_target: # zizmor: ignore[dangerous-triggers] safe here, this workflow only applies labels and never checks out or executes PR code

[dvdksn]

Good call — dropped the github.ref fallback in ba31bc5, so the group is now just ${{ github.workflow }}-${{ github.event.pull_request.number }} to match the other repos. Since the workflow only triggers on pull_request_target, pull_request.number is always set and the fallback was dead weight.

[dvdksn]

Added the zizmor ignore comment too (ba31bc5), with the context note on why the trigger is safe here (applies labels only, never checks out or executes PR code).

[thaJeztah]

changes LGTM; can you squash the commits?