tamada / sibling / 31152033634
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
31152033634

Pull #48

github

tamada 
ci: release through the reusable workflows of tamada/.github

The publish workflow did the tagging, the release, and the site deployment by
itself. Hand them to the reusable workflows, and keep here what only this
repository knows; building the command for each platform, and publishing the
crate.

- release-start tags main and opens the release as a draft,
- build-hugo-and-publish builds docs and deploys it to Pages, and
- release-finish takes the draft off with the token of the GitHub App.

The draft matters. The assets are attached while nobody knows about the
release, and the last job publishes it, which fires `release: published`;
the release published by GITHUB_TOKEN, as the old workflow did, fires nothing.
That is why notify-publish.yaml has never run once, and it will from now on.

The site deployment was broken in a quiet way. The Pages of this repository
serves what a workflow uploads (build_type: workflow), while the workflow
pushed the built site to the gh-pages branch; the job succeeded, the branch
moved, and Pages served the older site. It still tells v2.0.5 today, after the
release of v3.0.0. build-hugo-and-publish uploads the artifact to Pages, hence,
the deployment reaches the site.

Also quiet the shellcheck of versionup.yaml; the redirections were unquoted,
and it read a header into a variable which nothing used.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pull Request #48: Release through the reusable workflows of tamada/.github

1065 of 1149 relevant lines covered (92.69%)

12.42 hits per line

Jobs
ID Job ID Ran Files Coverage
1 31152033634.1 8
92.69
 GitHub Action Run
Source Files on build 31152033634