tamada / sibling / 31159746625
93%
main: 93%

LAST BUILD BRANCH: ci/deploy-page
DEFAULT BRANCH: main
Ran
Jobs 1
Files 8
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 92.689%. Remained the same
31159746625

Pull #49

github

tamada 
ci: deploy the document site on every change of docs on main

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>
Pull Request #49: Deploy the document site on every change of docs

1065 of 1149 relevant lines covered (92.69%)

12.44 hits per line

Jobs
ID Job ID Ran Files Coverage
1 31159746625.1 8
92.69
 GitHub Action Run
Source Files on build 31159746625