The macOS and Linux release scripts called the Gitea API with
`curl -sf`, which discards the response on failure. A rejected token
surfaced only as a JSON decode error from the release id lookup.
- Route API calls through gitea_api, which keeps the HTTP status and
the response body
- On failure print the status and Gitea's message, with a hint about
the token scope on 401/403, and exit
- Look up the release first and create it only on 404 instead of
ignoring every creation error
- Check the status of each asset upload
`mdrs selfupdate` replaced the running binary with whatever the release
endpoint returned, checking only that the transport succeeded. Nothing
proved the archive was the one the release publishes.
- Compare the downloaded archive against the release's `.sha256` asset
and abort the update on a mismatch.
- Report a release that publishes no checksum as unverified, rather
than letting its absence pass for a verified download.
- Exclude `.sha256` assets when matching the archive for the build
target: those assets carry the target name too.
- Write and upload a checksum beside every archive, from the Gitea
release workflow and the three local build scripts.
CI does not have macOS or Windows runners, so provide scripts to
build and optionally upload release archives locally.
- scripts/build-release-macos.sh — builds x86_64 and aarch64-apple-darwin
- scripts/build-release-windows.ps1 — builds x86_64-pc-windows-msvc
- scripts/.env.example — template for Gitea credentials
Both scripts read GITEA_TOKEN, GITEA_SERVER_URL, and GITEA_REPOSITORY
from the environment or from scripts/.env (which is gitignored).
Upload to Gitea is skipped when GITEA_TOKEN is not set.
Use curl.exe for multipart upload in the PowerShell script to support
Windows PowerShell 5.1 (Invoke-RestMethod -Form requires PS 6.1+).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
orrisroot
