> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pipefort.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

```yaml theme={null}
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:

```yaml theme={null}
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.