The release page has been empty since the first release: the workflow
attached the binaries and created the release with no body, so the
changelog lived only in the annotated tag, where nobody reads it.
The tag message, minus its subject line, is now set as the release notes.
Only an annotated tag has a message worth copying, and only a release
with no notes is filled, so re-running a failed release repairs an empty
one without overwriting notes somebody edited by hand afterwards.
The image has no jq, so the JSON string is escaped with sed and awk.
Checked locally against the real v0.10.0 tag text and a string with
quotes, backslashes, tabs, CRLF, backticks and $; each round-trips
through a JSON parser unchanged. Not run in the pipeline: the PATCH call
and the shallow tag clone's git commands are first exercised by the next
tag push, and a failure there fails the step rather than leaving the
notes silently empty.
go vet says nothing about import order, so when the move to git.ryuvia.com
rewrote every import path without re-sorting them -- the new path sorts before
github.com/..., where the old one sorted after -- both repos went through a
green CI run and a release unformatted.
Added to the release workflow as well as CI, so the two keep running the same
checks; ci.yaml's header claims exactly that, and a check in one but not the
other would quietly make it false.
The step handles gofmt's two failure modes separately because they do not look
alike: a misformatted file is listed on stdout with exit 0, so the failure has
to be raised by hand, while a file that does not parse prints nothing to stdout
and exits 2 -- which a plain emptiness test reads as success. Verified against
all three cases (clean, misformatted, unparseable) before committing.
The module path, the CI pipeline and the self-updater all named GitHub. They now
name the Gitea instance everything else already runs on.
The workflows are rewritten rather than translated, for the reason recorded in
ci.yaml: Gitea's runner image is ubuntu:22.04, whose nodejs is Node 12, so no JS
action runs there -- actions/checkout@v4 dies with a SyntaxError before doing
anything. Every step is shell and checkout is a plain clone, which this public
repo needs no credential for. upload-artifact/download-artifact are JS actions
too, and there is no artifact store here, so the job that builds the binaries is
the job that publishes them.
internal/updater keeps its release and asset types unchanged: Gitea's release
payload carries the same tag_name, and its attachments the same name and
browser_download_url, so only the URL, the Accept header and one error string
move. The asset naming in release.yaml is load-bearing for that matching.
This does strand already-installed binaries, which still poll api.github.com.
The GitHub repository is left in place and untouched, so they report themselves
up to date rather than erroring; its last release is the bridge, and crossing it
is a one-time manual download.
Niklas Ye