Repository navigation
Deploy the document site on every change of docs - #49
Merged
Merged
Conversation
The site was deployed by the release only, hence, a fix of the documents did not reach the site until the next release. Deploy it on the push to main which touches docs, and by hand through the dispatch. The job calls build-hugo-and-publish of tamada/.github, as the release did. The copied workflow it replaces did the same by its own steps, with two problems: it paired actions/upload-pages-artifact@v3 with actions/deploy-pages@v5, which are not of the same generation, and it had no concurrency group, while Pages rejects a second deployment in flight rather than queueing it. The documents job is dropped from the publish workflow with this. Both of them would run on the merge of a release branch, since a release changes the version badges of docs, and the two deployments would race for the single one Pages allows. Hugo is pinned at 0.158.0. The blowfish theme of docs/go.mod tells it works up to 0.154.5, and 0.158.0 builds this site as well; both were checked in a container. Pinning keeps a new Hugo from breaking the deployment unasked. Also drop prepare_site_build of the Justfile. It made a worktree of gh-pages on docs/public, which nothing serves from since Pages serves what a workflow uploads. 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.
Takes the workflow you added, and hands its body to the reusable
build-hugo-and-publish.yaml@v1— the same one the release used.What the copied workflow would have hit
actions/upload-pages-artifact@v3withactions/deploy-pages@v5concurrencygrouphugo-version: 0.158.0Its trigger is kept as it was: the push to
mainwhich touchesdocs, and themanual dispatch.
The site is deployed here now, not by the release
The
documentsjob is dropped frompublish.yaml. A release changes the versionbadges under
docs, so both would have run on the same merge and raced for thesingle deployment Pages allows.
A fix of the documents now reaches the site without waiting for a release, which
is the other half of why this is worth splitting.
Hugo
Pinned at
0.158.0. The blowfish theme ofdocs/go.moddeclares 0.141.0 to0.154.5; 0.141.0, 0.154.5, and 0.158.0 were each run against this site in a
container, and all of them build it. Pinning is deliberate:
latestis 0.164.0today, which nobody has tried here, and a failure would only show up as a site
which quietly stops updating.
After merging
The live site still tells v2.0.5. Running this workflow by hand brings it to
3.0.0.
Also drops
prepare_site_buildof the Justfile, which made a worktree ofgh-pagesondocs/public; nothing serves from that branch any more.🤖 Generated with Claude Code