Footer-Versionsnummer aus Forgejo Release (z. B. 2026.08.1) #3

New issue

Closed

opened 2026-08-18 08:10:15 +02:00 by Simon · 0 comments

Simon commented

2026-08-18 08:10:15 +02:00

Owner

Ziel

Im Footer der Homepage eine saubere Versionsnummer sehen (Format JJJJ.MM.N, z. B. 2026.08.1), die sich aus dem aktuellen Forgejo-Release ableitet. Simon fährt in Forgejo einen neuen Release → Deployment startet (wie eingerichtet) → Footer zeigt sofort die neue Version. Kein manuelles Anpassen im HTML.

Ausgangslage (geprüft)

Footer: index.html, .footer-bottom enthält aktuell Copyright © 2026 Bürgerinitiative EjUn + Claim-Zeile.
Nebenbefund: Die Zeile Stand: <span id="last-updated"> in der Service-Spalte setzt in app.js (loadNews()) das Browser-Datum (new Date()) – das ist kein echtes Aktualisierungsdatum. Beim Umstieg auf Release-Versionslogik entscheiden, ob diese Zeile entfällt oder zum echten Release-Release-Datum wird.
Forgejo-Repo Simon/ejun-page hat noch keine Releases → der erste Release wird 2026.08.1.
Abhängigkeit: Die Deploy-Pipeline (Forgejo Actions Runner, Deploy via SSH/scp auf die EjUn-VM 10.20.10.10) muss stehen. Ohne Runner löst ein Release kein Deployment aus.

Versions-Schema

Format: JJJJ.MM.N – Jahreszahl, Monatszahl (2-stellig), fortlaufende Release-Nummer pro Monat (N startet bei 1).
Beispiele: 2026.08.1, 2026.08.2 (zweites Release im August), 2026.09.1 (erstes im September).
Release-Tags in Forgejo exakt im Format 2026.08.1 anlegen (keine v-Präfixe, keine SemVer-1.0.0) – so bleibt die Zahl ohne Transformation im Footer.

Umsetzung

Build-Schritt im Deploy-Workflow: Bei jedem Release-Trigger den Release-Tag in eine statische Datei schreiben, z. B. /var/www/ejun-page/VERSION.txt (Inhalt: 2026.08.1). Die Datei reist per SCP mit – kein Runtime-Abgleich mit Forgejo nötig (die VM hat keine ausgehende Verbindung zu 10.10.10.x, daher kein fetch auf die Forgejo-API zur Laufzeit).
Footer-Anzeige: In index.html in .footer-bottom eine Versionszeile ergänzen, z. B. Version 2026.08.1 (dezente Darstellung, passend zur bestehenden Typografie). Anzeige per kleiner JS-Funktion, die VERSION.txt lädt (Cache-busting über den Dateinamen, da nginx statisch serviert) mit Fallback, z. B. –, falls das Laden fehlschlägt.
- Alternative (einfacher, kein JS): VERSION.txt-Inhalt im Deploy direkt in den HTML-Footer injizieren (sed). Vorteil: keine Runtime-Abhängigkeit; Nachteil: HTML wird bei jedem Deploy umgeschrieben. Entscheidung bei der Umsetzung, Empfehlung: statische Datei + JS, da der Footer-Code dann repo-stabil bleibt.
Nebenbefund last-updated: Bei Gelegenheit entscheiden – Entfall oder Belegung mit dem echten Release-Datum (steht im Release-Objekt, ebenfalls im Build in eine statische Größe/Datei legen).

Akzeptanzkriterien

Forgejo-Release 2026.08.1 in Simon/ejun-page angelegt
Release-Trigger startet den Deploy-Workflow (Runner steht)
Nach dem Deploy zeigt der Footer der Live-Seite 2026.08.1
Zweiter Test-Release 2026.08.2 → Footer zeigt nach dem Deploy 2026.08.2 (kein manueller Eingriff)
Fallback bei fehlender VERSION.txt ist unschön-frei (kein undefined, kein leerer Platzhalter ohne Hinweis)
VERSION.txt ist im Webroot lesbar, aber nicht Teil des sichtbaren Seitendesigns (reine Datendatei)

Abhängigkeiten

Forgejo Actions Runner installiert und betriebsbereit (Standort: Forgejo 10.10.10.32 oder hermes-lxc 10.10.10.34 – Entscheidung offen, beide erreichen die VM per SSH, ACL ist portbasiert: nur TCP 22 offen)
Deploy-Workflow vorhanden (git checkout → SCP nach 10.20.10.10 → nginx reload)
SSH-Zugang auf 10.10.10.32 für Runner-Installation (falls dort installiert)

Bemerkung

Keine Änderung am bestehenden Deploy-Mechanismus (SCP + nginx-reload, Backup nach /var/backups/ejun-deploy/). Die Versionsnummer ergänzt die Pipeline um genau einen Schritt (VERSION.txt schreiben) und eine Footer-Zeile.

## Ziel Im Footer der Homepage eine saubere Versionsnummer sehen (Format `JJJJ.MM.N`, z. B. `2026.08.1`), die sich aus dem aktuellen Forgejo-Release ableitet. Simon fährt in Forgejo einen neuen Release → Deployment startet (wie eingerichtet) → Footer zeigt sofort die neue Version. Kein manuelles Anpassen im HTML. ## Ausgangslage (geprüft) - Footer: `index.html`, `.footer-bottom` enthält aktuell `Copyright © 2026 Bürgerinitiative EjUn` + Claim-Zeile. - Nebenbefund: Die Zeile `Stand: <span id="last-updated">` in der Service-Spalte setzt in `app.js` (`loadNews()`) das **Browser-Datum** (`new Date()`) – das ist kein echtes Aktualisierungsdatum. Beim Umstieg auf Release-Versionslogik entscheiden, ob diese Zeile entfällt oder zum echten Release-Release-Datum wird. - Forgejo-Repo `Simon/ejun-page` hat **noch keine Releases** → der erste Release wird `2026.08.1`. - **Abhängigkeit:** Die Deploy-Pipeline (Forgejo Actions Runner, Deploy via SSH/scp auf die EjUn-VM 10.20.10.10) muss stehen. Ohne Runner löst ein Release kein Deployment aus. ## Versions-Schema - Format: `JJJJ.MM.N` – Jahreszahl, Monatszahl (2-stellig), fortlaufende Release-Nummer **pro Monat** (N startet bei 1). - Beispiele: `2026.08.1`, `2026.08.2` (zweites Release im August), `2026.09.1` (erstes im September). - Release-Tags in Forgejo exakt im Format `2026.08.1` anlegen (keine `v`-Präfixe, keine SemVer-1.0.0) – so bleibt die Zahl ohne Transformation im Footer. ## Umsetzung 1. **Build-Schritt im Deploy-Workflow:** Bei jedem Release-Trigger den Release-Tag in eine statische Datei schreiben, z. B. `/var/www/ejun-page/VERSION.txt` (Inhalt: `2026.08.1`). Die Datei reist per SCP mit – kein Runtime-Abgleich mit Forgejo nötig (die VM hat keine ausgehende Verbindung zu 10.10.10.x, daher kein `fetch` auf die Forgejo-API zur Laufzeit). 2. **Footer-Anzeige:** In `index.html` in `.footer-bottom` eine Versionszeile ergänzen, z. B. `Version 2026.08.1` (dezente Darstellung, passend zur bestehenden Typografie). Anzeige per kleiner JS-Funktion, die `VERSION.txt` lädt (Cache-busting über den Dateinamen, da nginx statisch serviert) mit Fallback, z. B. `–`, falls das Laden fehlschlägt. - Alternative (einfacher, kein JS): `VERSION.txt`-Inhalt im Deploy direkt in den HTML-Footer injizieren (sed). Vorteil: keine Runtime-Abhängigkeit; Nachteil: HTML wird bei jedem Deploy umgeschrieben. Entscheidung bei der Umsetzung, Empfehlung: statische Datei + JS, da der Footer-Code dann repo-stabil bleibt. 3. **Nebenbefund `last-updated`:** Bei Gelegenheit entscheiden – Entfall oder Belegung mit dem echten Release-Datum (steht im Release-Objekt, ebenfalls im Build in eine statische Größe/Datei legen). ## Akzeptanzkriterien - [ ] Forgejo-Release `2026.08.1` in `Simon/ejun-page` angelegt - [ ] Release-Trigger startet den Deploy-Workflow (Runner steht) - [ ] Nach dem Deploy zeigt der Footer der Live-Seite `2026.08.1` - [ ] Zweiter Test-Release `2026.08.2` → Footer zeigt nach dem Deploy `2026.08.2` (kein manueller Eingriff) - [ ] Fallback bei fehlender `VERSION.txt` ist unschön-frei (kein `undefined`, kein leerer Platzhalter ohne Hinweis) - [ ] `VERSION.txt` ist im Webroot lesbar, aber nicht Teil des sichtbaren Seitendesigns (reine Datendatei) ## Abhängigkeiten - Forgejo Actions Runner installiert und betriebsbereit (Standort: Forgejo 10.10.10.32 oder hermes-lxc 10.10.10.34 – Entscheidung offen, beide erreichen die VM per SSH, ACL ist portbasiert: nur TCP 22 offen) - Deploy-Workflow vorhanden (git checkout → SCP nach 10.20.10.10 → nginx reload) - SSH-Zugang auf 10.10.10.32 für Runner-Installation (falls dort installiert) ## Bemerkung Keine Änderung am bestehenden Deploy-Mechanismus (SCP + nginx-reload, Backup nach /var/backups/ejun-deploy/). Die Versionsnummer ergänzt die Pipeline um genau einen Schritt (VERSION.txt schreiben) und eine Footer-Zeile.

Simon referenced this issue from a commit

2026-08-18 10:09:47 +02:00

Deploy via Forgejo-Release + Footer-Versionsnummer aus Tag

Simon referenced this issue from a pull request that will close it,

2026-08-18 10:10:22 +02:00

Deploy via Forgejo-Release + Footer-Versionsnummer aus Tag #4

Simon closed this issue

2026-08-18 15:09:03 +02:00

Simon referenced this issue from a commit

2026-08-18 15:09:04 +02:00

Deploy via Forgejo-Release + Footer-Versionsnummer aus Tag

Simon referenced this issue