Gating the deploy on CI success (#12) cost the paths filter, because
workflow_run cannot carry one: every green CI run on main redeployed the site,
including the README-only merge in #13 that touched no published byte.
The question is now asked in a `changes` job whose answer gates build and
deploy. It compares docs/ against the commit behind the newest *successful*
github-pages deployment — what is actually live — rather than against HEAD^.
That distinction is the whole point:
- a push carrying several commits may hide the docs change in any of them,
and HEAD^ only sees the last one;
- if the previous deploy failed, the site is a version further behind than
the previous commit suggests, and HEAD^ would skip the deploy that fixes it.
Deploys anyway, deliberately, when there is no successful deployment to
compare against, when the live commit is missing from history (force push),
and on workflow_dispatch — manual dispatch means "publish now", not "check
whether I need to".
Both checkouts now pin ref to github.event.workflow_run.head_sha. For
workflow_run the default checkout is the branch tip, not the commit CI
validated, so two pushes in quick succession could publish the newer tree
under the older one's green tick. Empty on workflow_dispatch, where the
dispatched ref is already what we want.
Verified by extracting the step's script from the YAML and running it against
this repo's real history with the API stubbed at curl: docs-identical head
skips; failed-newest-deploy deploys; missing/absent/dispatch all deploy; a
genuine docs change deploys and lists the files. actionlint clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK
Claude
6adf26964e