Concurrency groups cancel the build nobody is waiting for

Three pushes in ten minutes start three builds, and the first two are testing code that has already been superseded.

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

# and the one place it must NOT cancel:
#   a deploy job. cancelling half a deploy is worse than
#   queueing behind one.
concurrency:
  group: deploy-production
  cancel-in-progress: false

Grouping on the ref rather than globally is what keeps two branches from cancelling each other, which is the mistake that makes the feature look broken. For deploys the same mechanism with cancellation off gives a queue rather than a race, which is what a deploy pipeline wants — two concurrent deploys to one environment is a state nobody can reason about. On a busy repository this halves the minutes bill without changing anything anyone notices.