Firmware CI releases + Gitea auto-update in the server
Build and push server image / build-and-push (push) Successful in 39s
Build and push server image / build-and-push (push) Successful in 39s
New Gitea Actions workflow builds both board variants and publishes them as release assets whenever firmware/version.txt is bumped. The server can now poll that repo's releases (next to the existing manual upload) and either surface an "Update frame" button or, with "Automatically apply updates" checked, stage the new build itself -- the frame still only updates on its own next wake either way.
This commit is contained in:
@@ -44,6 +44,18 @@ algorithm itself -- it just streams the response straight to the panel.
|
||||
the web UI without a valid token in the URL shows a plain token-entry
|
||||
prompt instead of the config UI; `/health` stays open regardless
|
||||
(pure liveness, nothing sensitive in it).
|
||||
7. **Optional: auto-update firmware from Gitea releases.** If you're
|
||||
pushing this repo to a Gitea instance, `.gitea/workflows/firmware-release-build.yml`
|
||||
builds both supported boards and publishes them as release assets
|
||||
(`firmware-xiao.bin`/`firmware-devkit.bin`) whenever `firmware/version.txt`
|
||||
changes on `main`. In the web UI's Settings form, set **Firmware Gitea
|
||||
repo URL** to that repo (e.g. `https://git.example.com/owner/repo`) and
|
||||
pick the frame's **board**; if the repo is private, also set
|
||||
`GITEA_FIRMWARE_TOKEN` (a read-only PAT) in `docker-compose.yml`. The
|
||||
server then periodically checks for a newer release and either shows
|
||||
an "Update frame" button or, with **Automatically apply updates**
|
||||
checked, stages it itself -- either way the frame only actually
|
||||
updates on its own next wake (see `POST /api/firmware` above).
|
||||
|
||||
## Endpoints
|
||||
|
||||
@@ -156,6 +168,18 @@ algorithm itself -- it just streams the response straight to the panel.
|
||||
- `GET /frame/firmware` -- streams back whatever was last uploaded via
|
||||
`POST /api/firmware`, for the device's OTA fetch. 404 if nothing's
|
||||
been uploaded yet
|
||||
- `GET /api/firmware/check` -- throttled (`gitea_releases.UPDATE_CHECK_INTERVAL_S`,
|
||||
15 min) check of the configured Gitea repo's latest release for the
|
||||
frame's board variant. `{"enabled": false}` if no repo URL is
|
||||
configured; otherwise `{"enabled": true, "latest_version": "1.2.3" | null,
|
||||
"staged_version": "1.2.2" | null, "update_available": bool}`. If
|
||||
"Automatically apply updates" is on and a newer release is found, this
|
||||
call also stages it immediately (same effect as a manual upload) --
|
||||
otherwise the web UI shows an "Update frame" button
|
||||
- `POST /api/firmware/apply-latest` -- the "Update frame" button: pulls
|
||||
and stages the latest Gitea release right now, bypassing the check
|
||||
throttle. 404 if no repo is configured, has no releases, or the latest
|
||||
release has no asset for the configured board variant
|
||||
- `GET /api/queue` -- `{"current": {...} | null, "upcoming": [...],
|
||||
"device": {"last_seen": ts | null, "overdue": bool,
|
||||
"firmware_version": "1.2.3" | null, "firmware_available": "1.2.4" | null,
|
||||
|
||||
Reference in New Issue
Block a user