Deploy the site from main, never from a release tag - #91
Merged
Conversation
Publish site has failed on almost every release, and the retry added in #84 did not fix it: dev 3286 deployed twice from its tag and the site took neither. That run also identified the cause. A Pages deployment made from a tag is not served unless it is the first deployment of that commit; one made from a branch supersedes whatever is live, first or not. Commit f169379 settles it - deployed from main at 13:59 it went live, deployed from tag v1.2.2-dev.3286 at 14:20 it stalled, twice. By the time a release is published its commit has usually been deployed from main already, so the release's own deployment is created, reported as succeeded, and dropped. A release therefore no longer deploys. It asks this workflow to run on main and that run deploys, carrying the tag as an input so the manifests still wait for the release to appear. workflow_dispatch is one of the two events exempt from the rule that GITHUB_TOKEN cannot start another run, so this needs no personal access token. The retry is removed rather than left beside the real fix: it is known not to work for the only failure it ever targeted, and keeping it would make it unclear which of the two was doing the work. Also moves off Node 20, which the runners now force to Node 24 anyway: configure-pages v5 to v6, deploy-pages v4 to v5, upload-pages-artifact v3 to v5 - the last of which is what drops the transitive upload-artifact v4. site/ has no dotfiles, so the change in upload-pages-artifact v4 that excludes them from the artifact drops nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The retry from #84 does not work. Dev 3286 was its first real test: it deployed, the site was stale, it deployed again, and the site was still stale. That run is also what finally identified the cause.
A Pages deployment made from a tag is not served unless it is the first deployment of that commit. One made from a branch supersedes whatever is live, first or not. Commit
f169379settles it:mainv1.2.2-dev.3286By the time a release is published, its commit has usually been deployed from
mainalready — the release tag, the pre-release tag andmainare all one commit — so the release's own deployment is created, reported as succeeded bydeploy-pages, and never served. Across the runs since the verify step existed: pushes 9 of 9, manual runs 8 of 8, release-triggered runs 7 of 23.So a release no longer deploys the site. The new
redeployjob asks this same workflow to run onmain, passing the release tag as an input so-ExpectTagstill stops the manifests being written before the release is listed.workflow_dispatchis one of the two events GitHub exempts from the rule thatGITHUB_TOKENcannot start another workflow run, so no personal access token is needed. A release now produces two runs: a three-line dispatcher on the tag, and the deployment onmain.The retry is removed rather than left beside the real fix. It is known not to work for the only failure it ever targeted, and leaving both in would make it unclear which one was doing the work. The verify step stays — that is what catches the problem.
Also clears the Node 20 deprecation warnings, which the runners already force to Node 24:
configure-pagesv5→v6,deploy-pagesv4→v5,upload-pages-artifactv3→v5. The last is what drops the transitiveupload-artifact@v4. Noteupload-pages-artifactv4 stopped including dotfiles in the artifact —site/has none, so nothing is silently dropped, and there is a comment saying what to do if one is ever added.Because the release path no longer sees the release event, the changelog check now reads the tag from the input and decides from its shape:
v1.2.2is checked,v1.2.2-dev.3286is skipped as a pre-release, empty means this is not a release deployment. All four branches were exercised locally, including that an unwritten version exits 1.This cannot be fully proved until the next release — the dispatcher only runs on a
releaseevent. What a merge does prove is the deploy path itself: the same steps onmain, on the new action versions.🤖 Generated with Claude Code