The release-action@main reads GITHUB_REF directly and rejects anything
that doesn't start with refs/tags/. The previous workflow tried to work
around this by passing tag_name as an action input, but the action's
action.yml never declared tag_name (or body_path) - both inputs were
silently ignored, which is why every Gitea release since v1.4.1 was
published with an empty body.
Changes:
- New "Validate tag ref" step fails fast with a clear message when the
workflow is dispatched from a branch ref instead of a tag ref.
- workflow_dispatch.inputs.tag dropped; recovery now means picking the
tag from Gitea's Ref dropdown so GITHUB_REF lines up with refs/tags/.
- release-body.md is re-emitted as a step output and passed via body:
(the input the action actually reads) instead of body_path.
- tag_name input removed from the action call - the action derives the
tag from GITHUB_REF_NAME on its own.
Both workflows looked for "**Hellion Chat <version>" as the changelog
subblock header, but the yaml convention is "**v<version> — <subtitle>"
(matches verify-changelog-sync.sh and the slim-rule grep). Plus the
indent-strip was 2 spaces, but prettier writes the changelog block with
4-space indent. Both regressions silently failed every release-workflow
run since the format change — likely why v1.4.3 was released manually.
Sync header marker to "**v$version " and indent-strip to 4 spaces in
both files.
Gitea Actions reads exclusively from .gitea/workflows/, not from
.github/workflows/. Since the cutover in v1.4.3 only the security
workflow has been running — release and forge-announce silently sat in
the wrong directory and never fired on any tag push. v1.4.3 must have
been released manually.
Move build, release and forge-announce yamls to .gitea/workflows/. The
.github/forge-posts/ and .github/release-footer.md data files stay where
they are; the workflows reference them by repo-relative path and that
keeps working.
For the v1.4.4 backfill: workflow_dispatch via the Gitea web UI with
tag=v1.4.4 will run release.yml + forge-announce.yml against the tagged
tree (which doesn't contain this migration). The dispatch yaml itself
is read from the default branch, not the tag, so the missing yamls in
the v1.4.4 tag tree don't matter.
JonKazama-Hellion