BEST-PRAC-4 — Deploy/release workflow has no concurrency guard

Overlapping runs of a deploy or release workflow race on shared caches, artifacts, and targets.

Field	Value
Category	BEST-PRAC-4
Severity	LOW
Confidence	HIGH
Persona	pedantic
Auto-fix	✓

What the check does

Flags a deploy/release-shaped workflow — one that publishes a release-shaped artifact or declares a job environment: — that has no concurrency: group at the workflow level (or on every job).

Why it matters

Without a concurrency guard, two runs that overlap (rapid pushes, a re-run during an in-flight run) execute simultaneously. For deploy and release workflows that means racing on the deploy target, shared caches, and release artifacts — producing double-deploys, clobbered uploads, or inconsistent state. This is a reliability and supply-chain-integrity concern, not an OWASP/SLSA control, so it lives in the best-practice bucket.

on:
  push:
    tags: ['v*']
jobs:
  release:                     # ← no concurrency: two tag pushes can race
    runs-on: ubuntu-latest
    steps:
      - run: gh release create ${{ github.ref_name }}

Safe alternative

Add a top-level concurrency: block keyed to the workflow and ref:

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

Auto-fix

pipefort --fix (and the web app’s fix button) inserts exactly this block at the top of the workflow.