sqzass.git

sqzass

~ A static site generator written in Rust
git clone https://github.com/debuman/sqzass.git
commit 6b2845b0db346b79379f17444877e1a05e216e12
parent 21014fcefe2efa3f3aa386e2aeca9db5d6538423
Author: sqzer <110329244+sqzer-x@users.noreply.github.com>
Date: Sun, 26 Jul 2026 00:02:42 +0900

Retry a Pages deployment that lost a race with the previous one

`concurrency: group: pages` serialises workflow *runs*. It does not serialise
what GitHub does after one finishes — the Pages deployment outlives the run that
created it, and a run that starts inside that window gets a 400: "Deployment
request failed … due to in progress deployment."

Pushing four commits inside ten minutes hit it. One deploy was cancelled out of
the queue by the next arrival and two more failed against a deployment the
Deployments API was already reporting as successful.

So the deploy step now tolerates that one failure, waits, and tries once more.
It is safe to retry precisely because the request fails before changing
anything: there is no half-deployed state to land in, only a deployment that was
never created.

This does not fix the case where GitHub's own state is stuck rather than merely
busy — the cancel endpoint answering "already finished" while the deploy
endpoint says "still in progress" is not something a workflow can resolve. For
that the answer is to re-run once it clears.

Diffstat:
M.github/workflows/pages.yml | 19++++++++++++++++++-