robert/todo
Watch
1
0
Fork
You've already forked todo
 0
Code Issues 3 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Versionsnummer in den Einstellungen sichtbar machen #191

New issue
Closed
opened 2026-09-12 00:02:30 +02:00 by lena · 2 comments
lena commented 2026-09-12 00:02:30 +02:00
Collaborator
Copy link

Story: Versionsnummer in den Einstellungen sichtbar machen

As a Nutzer (oder jemand, der beim Debuggen hilft),
I want to in den Einstellungen der Live-Version nachsehen können, welche Version der App gerade läuft,
so that sich leicht prüfen lässt, ob ein erwartetes Feature/Fix schon deployed ist, bzw. welcher Stand bei einem Bug-Report gemeldet werden muss.

Kontext (verifiziert im Code):

  • Es gibt aktuell keinerlei Versions-/Build-Kennzeichnung irgendwo im Code (weder Backend noch Frontend) - kein AppVersion, BuildVersion, GitVersion o. ä., keine Anzeige in den Settings.

Acceptance criteria:

  • Die Einstellungen zeigen eine Versionskennung (z. B. Kurz-Commit-Hash und/oder Build-/Deploy-Zeitstempel) der aktuell laufenden Version an.
  • Die Kennung wird automatisch beim Build/Deploy gesetzt, nicht manuell gepflegt (z. B. aus der Git-Commit-SHA zum Build-Zeitpunkt).
  • Backend und Frontend zeigen konsistent dieselbe Version (oder sind zumindest beide erkennbar, falls sie durch ein Deployment-Timing-Fenster kurzzeitig auseinanderlaufen könnten).

Open questions (escalate to human if unanswered):

  • Reicht ein kurzer Commit-Hash, oder wird eine "richtige" semantische Versionsnummer (z. B. 0.42.0) gewünscht, die separat hochgezählt werden müsste?
## Story: Versionsnummer in den Einstellungen sichtbar machen **As a** Nutzer (oder jemand, der beim Debuggen hilft), **I want to** in den Einstellungen der Live-Version nachsehen können, welche Version der App gerade läuft, **so that** sich leicht prüfen lässt, ob ein erwartetes Feature/Fix schon deployed ist, bzw. welcher Stand bei einem Bug-Report gemeldet werden muss. **Kontext (verifiziert im Code):** - Es gibt aktuell keinerlei Versions-/Build-Kennzeichnung irgendwo im Code (weder Backend noch Frontend) - kein `AppVersion`, `BuildVersion`, `GitVersion` o. ä., keine Anzeige in den Settings. **Acceptance criteria:** - [ ] Die Einstellungen zeigen eine Versionskennung (z. B. Kurz-Commit-Hash und/oder Build-/Deploy-Zeitstempel) der aktuell laufenden Version an. - [ ] Die Kennung wird automatisch beim Build/Deploy gesetzt, nicht manuell gepflegt (z. B. aus der Git-Commit-SHA zum Build-Zeitpunkt). - [ ] Backend und Frontend zeigen konsistent dieselbe Version (oder sind zumindest beide erkennbar, falls sie durch ein Deployment-Timing-Fenster kurzzeitig auseinanderlaufen könnten). **Open questions (escalate to human if unanswered):** - Reicht ein kurzer Commit-Hash, oder wird eine "richtige" semantische Versionsnummer (z. B. `0.42.0`) gewünscht, die separat hochgezählt werden müsste?
lena self-assigned this 2026-09-30 15:30:57 +02:00
lena commented 2026-09-30 15:30:58 +02:00
Author
Collaborator
Copy link

Claimed by session "Go [76d2a8]"

Starting work. Open question resolved autonomously (PO): a short Git commit hash plus build timestamp is enough - no separately maintained semantic version (would violate the "set automatically, not maintained by hand" criterion). Plan: CI/Docker pass the commit SHA + build time as build args; backend exposes them via the existing health/version endpoint; frontend bakes its own SHA in at build time; Settings shows both and flags a mismatch.

Claimed by session "Go [76d2a8]" Starting work. Open question resolved autonomously (PO): a short Git commit hash plus build timestamp is enough - no separately maintained semantic version (would violate the "set automatically, not maintained by hand" criterion). Plan: CI/Docker pass the commit SHA + build time as build args; backend exposes them via the existing health/version endpoint; frontend bakes its own SHA in at build time; Settings shows both and flags a mismatch.
lena commented 2026-09-30 15:46:25 +02:00
Author
Collaborator
Copy link

Done - pushed to master (8f09e166, 0fba8028, 5bfeb2bf, 3856ddcd, plus a QA memory entry 9ff77cc4).

Scope

  • Settings dialog now shows a small footer on every tab: Version <short commit> - Built <local date/time>.
  • If the browser still runs an older cached bundle than the server, it shows both (App abc1234 - Server def5678) plus a hint that reloading fetches the current app.
  • Backend: new GetAppVersionQuery (authenticated, like every feature endpoint) returning commit + build time from the AppVersion config section.
  • Build: the Dockerfile takes APP_COMMIT/APP_BUILD_TIME build args and bakes them into both the frontend bundle (VITE_APP_*) and the backend env (AppVersion__*) from the same build, so the two halves of one image always agree. CI's docker job passes github.sha and the UTC build time. The local review container (docker-compose.dev.yml) accepts the same args via env and reports local when unset. Plain dotnet run/npm run dev reports dev.

Decisions

  • Open question resolved: commit hash + build timestamp, no separately maintained semantic version (the acceptance criteria require it to be set automatically, never by hand).
  • The endpoint's auth gate is not a secrecy measure - the same hash is in the public JS bundle; it only follows the standard feature-endpoint pattern (security review note, comment corrected).

Tests

  • Backend: GetAppVersionQueryHandlerTests (configured values, unset fallback to dev, blank commit treated as dev); full Checkly.Tests suite green (1129).
  • Frontend: AppVersionInfo.test.tsx (7 tests: match, build time, unparseable build time, mismatch + hint, backend failure, closed dialog makes no call, non-hash label kept); full vitest suite green (1597); npm run build green.
  • Verified live in the rebuilt review container: Settings footer showed the real commit and build time.

Security review: no findings (one informational note, addressed by the comment fix above).

Done - pushed to master (8f09e166, 0fba8028, 5bfeb2bf, 3856ddcd, plus a QA memory entry 9ff77cc4). **Scope** - Settings dialog now shows a small footer on every tab: `Version <short commit> - Built <local date/time>`. - If the browser still runs an older cached bundle than the server, it shows both (`App abc1234 - Server def5678`) plus a hint that reloading fetches the current app. - Backend: new `GetAppVersionQuery` (authenticated, like every feature endpoint) returning commit + build time from the `AppVersion` config section. - Build: the Dockerfile takes `APP_COMMIT`/`APP_BUILD_TIME` build args and bakes them into both the frontend bundle (`VITE_APP_*`) and the backend env (`AppVersion__*`) from the same build, so the two halves of one image always agree. CI's docker job passes `github.sha` and the UTC build time. The local review container (`docker-compose.dev.yml`) accepts the same args via env and reports `local` when unset. Plain `dotnet run`/`npm run dev` reports `dev`. **Decisions** - Open question resolved: commit hash + build timestamp, no separately maintained semantic version (the acceptance criteria require it to be set automatically, never by hand). - The endpoint's auth gate is not a secrecy measure - the same hash is in the public JS bundle; it only follows the standard feature-endpoint pattern (security review note, comment corrected). **Tests** - Backend: `GetAppVersionQueryHandlerTests` (configured values, unset fallback to `dev`, blank commit treated as `dev`); full Checkly.Tests suite green (1129). - Frontend: `AppVersionInfo.test.tsx` (7 tests: match, build time, unparseable build time, mismatch + hint, backend failure, closed dialog makes no call, non-hash label kept); full vitest suite green (1597); `npm run build` green. - Verified live in the rebuilt review container: Settings footer showed the real commit and build time. **Security review:** no findings (one informational note, addressed by the comment fix above).
lena 2026-09-30 15:46:25 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feature/in-app-notifications
feature/list-archiving
feature/filter-search
No results found.
Labels
Clear labels   
priority/could

   
priority/must

   
priority/should

   
priority/wont

   
status/blocked

   
status/claimed

   
status/done-migrated

   
type/bug

   
type/feature

   
type/infra

   
type/tech-debt
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
lena
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
robert/todo#191
No description provided.