Publish: verify the release's stored state after attaching the APK
Build and Release APK / Build APK and publish release (push) Canceled after 0s

A live publish on git.wallacenet.ca kept coming back invisible to the updater:
the create accepted "draft": false, and the release was still stored as a
draft once the APK was attached — so the anonymous list the app reads came
back empty even though every publish step reported success.

The script now attaches first, then reads the release back and PATCHes the
state if it did not stick, failing loudly if the correction is refused. A
draft is not a channel a preview build can silently become.

Also lists all 22 catalogue games in the README's table; seven were missing,
which read as "the app has 15 games".

Verified against the live instance: anonymous list shows
v1.4.1001-dev as a published prerelease with a tag-named asset, the
production /releases/latest correctly returns 404 while only a prerelease
exists, and an anonymous download through the URL the app builds matches the
built APK byte for byte.

Co-Authored-By: Paperclip <[email protected]>
This commit is contained in:
adrianoftyriel
2026-10-13 22:27:33 +00:00
co-authored by Paperclip
parent a827a38ae6
commit 05c443a4b5
3 changed files with 36 additions and 6 deletions
+9 -4
View File
@@ -97,10 +97,15 @@ GITEA_TOKEN=… ./scripts/publish-release.sh v1.4.1001 app/build/outputs/apk/deb
```
The script takes `<tag> <apk> <prerelease|release> [target-sha]`, creates the
release through `POST /api/v1/repos/{owner}/{repo}/releases`, and attaches the
APK through `POST …/releases/{id}/assets` — which is the upload route Gitea's
Swagger declares for this instance (1.27.3). If the tag already exists it
publishes into the existing release instead of failing, so a retry is safe.
release through `POST /api/v1/repos/{owner}/{repo}/releases`, attaches the APK
through `POST …/releases/{id}/assets` — which is the upload route Gitea's
Swagger declares for this instance (1.27.3) — and then reads the release back
and corrects its state if it did not stick. That last step is not decoration:
this instance has been observed to accept `draft: false` at create time and
store the release as a draft after the attachment lands, and a draft is
invisible to the updater, so the script verifies rather than assumes. If the
tag already exists it publishes into the existing release instead of failing,
so a retry is safe.
## What the in-app updater reads