tiennm99 160a20125e fix(ci): give each ref its own concurrency lane ...

The group was the literal string "pages", so every run of this workflow
shared one lane regardless of branch, and cancel-in-progress meant the
newest arrival won. A pull-request run therefore cancels an in-flight
deploy of main.

That is not theoretical: the deploy of #10 was killed 3m22s in by a
pull-request run that started after it, and the site quietly stayed on
the previous build. Nothing reported a failure — the PR checks were
green and the deploy showed "cancelled", which reads like something
someone chose.

Keyed by ref, a push still cancels its own superseded run, which is the
case worth cancelling, and a branch can no longer interrupt a deploy.

Also drops "compress it" from the pipeline comment: the databases have
shipped uncompressed since they started being read by range request.

2026-08-14 14:25:40 +07:00

..

deploy-pages.yml

fix(ci): give each ref its own concurrency lane

2026-08-14 14:25:40 +07:00