fix: split docker-build.yml concurrency group by event_name to eliminate push/pull_request race

[Wikid82]

Summary

• Appends -${{ github.event_name }} to docker-build.yml's concurrency.group key so push and pull_request runs for the same branch land in categorically different concurrency groups and can never cancel each other, regardless of registration order.
• Extends the explanatory comment above push.branches to note the group split and cross-reference Redesign docker-build.yml concurrency group to eliminate residual push/pull_request race #1235, so a future reader doesn't assume the concurrency group and the job-level if: skip (added in fix: skip redundant pull_request docker-build run for main/development-head PRs #1236) are redundant.
• Single-line functional change + one comment block. No other line in the 1340-line file is touched (verified by diff review below).

Closes #1235.

Why (production incident)

#1236 added a job-level if: skip so a pull_request run for a main/development-head PR self-resolves to a clean skipped conclusion instead of a misleading cancelled red X. But that fix can only clean up the reported status of whichever run loses the concurrency slot — GitHub decides which run to cancel at workflow-run registration time, before any job's if: is evaluated, so it cannot influence which run wins.

This was proven in production within minutes of #1236 merging to main (merge commit 6ed08db3):

Run ID	Event	Conclusion	Created
31429516203	push	cancelled	2026-08-10T20:32:22Z
31429519329	pull_request	skipped	2026-08-10T20:32:24Z

The push run — the one supposed to do the real build — was cancelled, not the pull_request run. Net effect: zero real builds for the commit that landed on main, and the published image tag went stale until a manual workflow_dispatch rebuild was run as a stopgap.

Research summary (full detail in docs/plans/current_spec.md §3)

Before merging this, every workflow that consumes docker-build.yml's workflow_run completion event was re-checked, since splitting the concurrency group means each race commit now produces two workflow_run completion events instead of (at best) one — one from push (real build outcome) and one from pull_request (always skipped, structurally guaranteed by #1236's unchanged job-level gate).

Verdict: safe to change only this file. All nine workflow_run: workflows: ["Docker Build, Publish & Test"] consumers were read in full:

#	File	Gate	Verdict
1	auto-changelog.yml	conclusion == 'success'	Safe
2	auto-versioning.yml	conclusion == 'success'	Safe
3	docs-to-issues.yml	conclusion == 'success'	Safe
4	docs.yml (build)	conclusion == 'success'	Safe. (deploy job has a pre-existing, unrelated gap — not caused/worsened by this PR — tracked separately as #1237)
5	dry-run-history-rewrite.yml	conclusion == 'success'	Safe
6	history-rewrite-tests.yml	conclusion == 'success'	Safe
7	propagate-changes.yml	conclusion == 'success'	Safe
8	security-pr.yml	event == 'pull_request' && conclusion == 'success'	Safe (double-gated)
9	supply-chain-verify.yml	excludes any workflow_run.event == 'pull_request' outright	Safe (most explicit)

Every consumer gates on conclusion == 'success' (directly or transitively), and the pull_request-sourced race event is structurally guaranteed to conclude skipped — so none of the nine treat it as actionable. No other file requires a change.

Also confirmed:

• fix: skip redundant pull_request docker-build run for main/development-head PRs #1236's job-level skip (setup job if:, unchanged by this PR) gates purely on event_name/head_ref, not on concurrency grouping — so it continues to correctly prevent a redundant real build on the pull_request side regardless of which group it's in.
• scan-pr-image's if: depends only on intra-run needs: outputs, never on the concurrency group.
• No branch protection or ruleset on main/development depends on docker-build.yml reporting exactly one conclusion per commit (verified live via gh api repos/Wikid82/Charon/branches/main/protection → 404, and the one active ruleset has no required_status_checks rule).

Follow-up issues filed

• docs.yml deploy job doesn't gate on build job's success/skip status #1237 — docs.yml's deploy job doesn't gate on needs.build.result == 'success' (pre-existing, unrelated to this fix, low priority).
• Post-merge monitoring: verify docker-build.yml push/pull_request race is actually eliminated (GH #1235 follow-up) #1238 — Post-merge monitoring: verify the push/pull_request race is actually eliminated once a real main/development-head sync PR event occurs (this fix's own acceptance criterion, since a true simultaneous race couldn't be safely constructed pre-merge — see Validation below).

Validation

• actionlint .github/workflows/docker-build.yml — zero errors
• actionlint .github/workflows/*.yml — zero errors (full-directory check, since actionlint validates cross-file workflow_run references)
• lefthook run pre-commit — zero errors (all fast hooks, including actionlint and semgrep)
• Manual diff review — confirmed only the group: line and the one comment block changed, nothing else in the 1340-line file
• Live: this PR's own pull_request run watched end-to-end on the feature branch head (see PR checks) — confirms the new concurrency group value doesn't break an ordinary feature-branch PR run
• Not achievable pre-merge: a true simultaneous push + pull_request race against main/development requires either unsafely pushing directly to a real production branch, or standing up disproportionate scratch infrastructure — both explicitly rejected. Full confirmation deferred to Post-merge monitoring: verify docker-build.yml push/pull_request race is actually eliminated (GH #1235 follow-up) #1238 (next organic race event, checked via gh run list --workflow=docker-build.yml).

Do not merge yet — pending final review.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-actions]

✅ Supply Chain Verification Results

✅ PASSED

📦 SBOM Summary

• Components: 1495

🔍 Vulnerability Scan

Severity	Count
🔴 Critical	0
🟠 High	0
🟡 Medium	5
🟢 Low	2
Total	14

📎 Artifacts

• SBOM (CycloneDX JSON) and Grype results available in workflow artifacts

---

_{Generated by Supply Chain Verification workflow • View Details}

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.