The article highlights a problem in GitHub Actions: using cancel-in-progress: true in a concurrency group can silently cancel in-progress deploy runs when multiple pushes occur, causing commits to be dropped from production.

The symptom is clear: simultaneous pushes from multiple code runners lead to one run being canceled, so some commits never reach production.

The root cause is misusing cancel-in-progress: true in deploy workflows; this is acceptable for CI but harmful for deploys that must include every commit.

This pitfall is easy to miss because default examples favor canceling in-progress for efficiency, which works for CI but not for deploy pipelines with many contributors or high-frequency pushes.

There’s a queueing overhead when many pushes occur: worst-case wait times can be long, and deploys tolerate longer queues better than CI jobs.

A decision matrix contrasts CI versus deploy workflows and whether to cancel in-progress runs, clarifying when each setting is appropriate.

A practical implementation is shown: adjust the workflow file to include group: ${{ github.workflow }}-${{ github.ref }} and cancel-in-progress: false to preserve cross-branch parallelism and in-order deployment per branch.

An example demonstrates the actual fix in a deploy-prod.yml snippet, illustrating the practical change needed to preserve commits across branches with cross-branch parallelism.

The proposed fix is to set cancel-in-progress: false, ensuring new runs queue and deploy in order so all commits are deployed.

The article provides concrete examples and numbers, including maximum wait times and a realistic impact assessment for deploy versus CI workloads.

Additionally, the implementation details show how to combine a unique group identifier with the cancel-in-progress setting to maintain order across branches.

Overall, the guidance is to preserve every commit in production by avoiding cancellation of in-progress deploys and tuning concurrency settings accordingly.