Show app version in UI with update-available check against Forgejo #27

New issue

Closed

opened 2026-06-24 00:32:14 +00:00 by rbrooks · 0 comments

rbrooks commented

2026-06-24 00:32:14 +00:00

Owner

Target release: v1.1.0

Surface the running WeatherBot version in the app, keep it accurate automatically across releases, and warn when a newer release exists.

Requirements

Display the current version somewhere visible (e.g. footer and/or /diagnostics).
The version updates automatically on release — no manual edit per release. Source it from the release tag at build time (e.g. bake git describe --tags / the tag into the image as a build arg or generated app/_version.py, exposed via settings/health). Today app/main.py hard-codes version="1.0.0"; that should become the single source of truth fed from the tag.
Update check against Forgejo: query the Forgejo releases API for the latest published release (GET /api/v1/repos/rbrooks/WeatherBot/releases/latest) and compare to the running version; show an "update available → vX.Y.Z" indicator when behind.
Make the update check resilient: cached/throttled (don't hit the API on every page load), non-blocking, and silently degrade if the API is unreachable.
Surface it to admins/operators (the diagnostics page is a natural home; a small footer badge is optional).

Notes / decisions

Build-time stamping pairs naturally with the CI/CD work (#12) — the deploy/build step can pass the tag.
Decide comparison semantics (exact tag match vs. semver-newer) and whether prereleases count.
The Forgejo instance and repo are public, so the releases API is readable without auth.

Source: user request.

**Target release:** v1.1.0 Surface the running WeatherBot version in the app, keep it accurate automatically across releases, and warn when a newer release exists. **Requirements** - [ ] Display the current version somewhere visible (e.g. footer and/or `/diagnostics`). - [ ] The version updates **automatically on release** — no manual edit per release. Source it from the release tag at build time (e.g. bake `git describe --tags` / the tag into the image as a build arg or generated `app/_version.py`, exposed via settings/health). Today `app/main.py` hard-codes `version="1.0.0"`; that should become the single source of truth fed from the tag. - [ ] **Update check against Forgejo**: query the Forgejo releases API for the latest published release (`GET /api/v1/repos/rbrooks/WeatherBot/releases/latest`) and compare to the running version; show an "update available → vX.Y.Z" indicator when behind. - [ ] Make the update check resilient: cached/throttled (don't hit the API on every page load), non-blocking, and silently degrade if the API is unreachable. - [ ] Surface it to admins/operators (the diagnostics page is a natural home; a small footer badge is optional). **Notes / decisions** - Build-time stamping pairs naturally with the CI/CD work (#12) — the deploy/build step can pass the tag. - Decide comparison semantics (exact tag match vs. semver-newer) and whether prereleases count. - The Forgejo instance and repo are public, so the releases API is readable without auth. Source: user request.

rbrooks added the

labels

2026-06-24 00:32:47 +00:00

rbrooks added this to the v1.1.0 - Operations & observability (+ CD) milestone

2026-06-24 00:32:48 +00:00

rbrooks referenced this issue from a commit

2026-06-24 01:30:44 +00:00

Show app version in UI with Forgejo update check