Problem
.github/workflows/docs.yml:17-18 has a comment stating: "A newer push to main supersedes an in-flight deploy rather than queueing behind it." The actual config directly below it, cancel-in-progress: false (line 21), means the opposite: the in-progress run is not cancelled, and a newer run in the same pages concurrency group waits until the in-flight run finishes.
cancel-in-progress: false is the standard GitHub Pages template setting, specifically chosen to let a production deploy finish rather than being interrupted midway. Making a newer push actually supersede an in-flight one would require cancel-in-progress: true — the opposite of what's configured.
Impact
Two commits land on main in quick succession. A maintainer trusting the comment expects the first (now-stale) deploy to be cancelled in favor of the second; instead, the first deploy runs to completion and briefly publishes older content before the second deploy starts. The "supersede" behavior the comment describes never actually happens, so anyone debugging a transient stale-docs deploy is misdirected by the comment into looking for the wrong cause.
Suggested fix
Fix the comment to describe the actual (queue-behind, don't-cancel) behavior, or — if superseding is actually the intended behavior — flip cancel-in-progress to true to match the comment.
Problem
.github/workflows/docs.yml:17-18has a comment stating: "A newer push to main supersedes an in-flight deploy rather than queueing behind it." The actual config directly below it,cancel-in-progress: false(line 21), means the opposite: the in-progress run is not cancelled, and a newer run in the samepagesconcurrency group waits until the in-flight run finishes.cancel-in-progress: falseis the standard GitHub Pages template setting, specifically chosen to let a production deploy finish rather than being interrupted midway. Making a newer push actually supersede an in-flight one would requirecancel-in-progress: true— the opposite of what's configured.Impact
Two commits land on
mainin quick succession. A maintainer trusting the comment expects the first (now-stale) deploy to be cancelled in favor of the second; instead, the first deploy runs to completion and briefly publishes older content before the second deploy starts. The "supersede" behavior the comment describes never actually happens, so anyone debugging a transient stale-docs deploy is misdirected by the comment into looking for the wrong cause.Suggested fix
Fix the comment to describe the actual (queue-behind, don't-cancel) behavior, or — if superseding is actually the intended behavior — flip
cancel-in-progresstotrueto match the comment.