Let a newer Deploy Docs run cancel the one in progress
On 2026-10-01 GitHub left one Deploy Docs run queued and never gave it a runner. It held the deploy-docs concurrency group for 25 hours, so each later run sat pending until the next merge replaced it, and the site missed nearly five hours of merges until the stuck run was cancelled by hand.
This sets cancel-in-progress: true on that group, so a new run cancels the run holding the group instead of waiting behind it. Nothing else in the workflow changes.
Cancelling a deploy part-way is safe in this workflow:
scripts/build-docs.shfetches and builds the tips ofmainandv1.x, not the triggering commit, so a newer run publishes everything the cancelled one would have.- The site goes to Pages as one artifact in one deployment request, so a cancelled run leaves the live site as it was.
deploy-pagesalso cancels its own pending deployment when the job is cancelled. - No other step leaves anything behind. The artifact belongs to its own run,
configure-pagesonly reads, and the uv cache is saved only after a successful job. - No other workflow uses the
deploy-docsgroup or thegithub-pagesenvironment.
The cost is a wasted build when two merges land within about two minutes of each other: the first run is cancelled and the second publishes both. If the second commit breaks the docs build, the first one's content waits for the fix as well, which the docs check on pull requests is there to catch.
One point hasn't been observed. GitHub's docs describe cancel-in-progress as cancelling a "currently running" job or workflow in the group. The stuck run held the group while queued with no runner, and it isn't confirmed that such a run is cancelled the same way. If it isn't, the behaviour is the same as today.
Checked with prettier, zizmor and actionlint. The workflow file is in its own paths filter, so merging this runs a deploy.