The Continuous Delivery workflow uses a static concurrency group in .github/workflows/continuous-delivery.yml:
concurrency:
group: "pages"
cancel-in-progress: false
Because the group is a constant string, every branch shares one queue. GitHub's concurrency model keeps at most one run per group in the pending slot: when a newer run joins the group, the previously pending run is cancelled, regardless of cancel-in-progress. That flag only protects the run that is currently executing, not a queued one.
When Renovate opens a batch of PRs within a few seconds, their CD runs stack up in the same group and the earlier pending ones get cancelled with zero jobs executed. That is how #71 slipped in: its CD run was cancelled at 08:49:27 (see https://github.com/cloudnative-pg/docs/actions/runs/24657277312) before it could fail, and the PR was merged five minutes later without the build ever running.
Fix: scope the group per-branch, for example pages-${{ github.ref }}. Pending runs on different branches no longer supersede each other, while the existing "one deployment at a time on main" behaviour is preserved.
The
Continuous Deliveryworkflow uses a static concurrency group in.github/workflows/continuous-delivery.yml:Because the group is a constant string, every branch shares one queue. GitHub's concurrency model keeps at most one run per group in the pending slot: when a newer run joins the group, the previously pending run is cancelled, regardless of
cancel-in-progress. That flag only protects the run that is currently executing, not a queued one.When Renovate opens a batch of PRs within a few seconds, their CD runs stack up in the same group and the earlier pending ones get cancelled with zero jobs executed. That is how #71 slipped in: its CD run was cancelled at 08:49:27 (see https://github.com/cloudnative-pg/docs/actions/runs/24657277312) before it could fail, and the PR was merged five minutes later without the build ever running.
Fix: scope the group per-branch, for example
pages-${{ github.ref }}. Pending runs on different branches no longer supersede each other, while the existing "one deployment at a time onmain" behaviour is preserved.