|
|
|
|
@@ -41,13 +41,13 @@ Die Pipeline nutzt die fest gepinnten Pakete `@semantic-release/commit-analyzer`
|
|
|
|
|
|
|
|
|
|
Es zählt der höchste erforderliche Sprung seit dem letzten stabilen Tag `vMAJOR.MINOR.PATCH`. Eine Änderung und ihr vollständiger Git-Revert innerhalb desselben Release-Bereichs heben sich auf. Selbst verfasste Nachrichten müssen dem Schema entsprechen; echte Merge-Commits und automatisch generierte Git-Reverts werden gesondert behandelt.
|
|
|
|
|
|
|
|
|
|
Der erste Release heißt `1.0.0`. `bootstrapCommit` in `release.config.json` begrenzt die Prüfung und die erste Änderungsliste auf die Einführung dieser Versionierung. Ältere Commits werden weder umgeschrieben noch nachträglich klassifiziert. Den Ausgangscommit nach Einführung nicht ändern.
|
|
|
|
|
Der erste Release heißt `3.0.0`. `bootstrapCommit` in `release.config.json` begrenzt die Prüfung und die erste Änderungsliste auf die Einführung dieser Versionierung. Ältere Commits werden weder umgeschrieben noch nachträglich klassifiziert. Den Ausgangscommit nach Einführung nicht ändern.
|
|
|
|
|
|
|
|
|
|
## Versionen und Artefakte
|
|
|
|
|
|
|
|
|
|
Backend, Frontend, Dokumentation, Website und zentrale Dienste werden als gemeinsamer FEDEO-Stand gebaut. Die Produktversion stammt aus Git und wird beim Build eingebettet. Backend-/Frontend-Paketversionen dienen nicht als Release-Quelle.
|
|
|
|
|
|
|
|
|
|
- Stabile Images: `…/backend:1.2.0`, `…/backend:v1.2.0` und `…/backend:sha-<vollständiger Commit>`; entsprechend für alle sechs Komponenten.
|
|
|
|
|
- Stabile Images: `…/backend:3.2.0`, `…/backend:v3.2.0` und `…/backend:sha-<vollständiger Commit>`; entsprechend für alle sechs Komponenten.
|
|
|
|
|
- Bewegliche Kanäle: `latest` und `main` zeigen nach erfolgreicher Veröffentlichung auf denselben Release.
|
|
|
|
|
- Entwicklung: `dev` sowie unveränderliche `dev-sha-<vollständiger Commit>`-Images. Die eingebettete Entwicklungsversion enthält Commit-Anzahl und Commit-ID.
|
|
|
|
|
- Jeder Build erhält zunächst einen eindeutigen temporären `build-<UUID>`-Tag. Diese Tags können später nach einer Aufbewahrungsfrist bereinigt werden; stabile Versionen und deren Digests müssen erhalten bleiben.
|
|
|
|
|
@@ -65,7 +65,7 @@ Im Frontend steht die Version unten in der Seitenleiste; der Tooltip enthält de
|
|
|
|
|
curl https://app.example.com/backend/version
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Beispiel: `{"product":"FEDEO","version":"1.2.0","revision":"<Commit-ID>"}`. Die zentrale Instanzmeldung verwendet dieselbe Backend-Version. Bei lokalen Builds ohne Build-Argumente lautet die Version `0.0.0-dev`.
|
|
|
|
|
Beispiel: `{"product":"FEDEO","version":"3.2.0","revision":"<Commit-ID>"}`. Die zentrale Instanzmeldung verwendet dieselbe Backend-Version. Bei lokalen Builds ohne Build-Argumente lautet die Version `0.0.0-dev`.
|
|
|
|
|
|
|
|
|
|
## Gitea einmalig vorbereiten
|
|
|
|
|
|
|
|
|
|
@@ -107,20 +107,20 @@ Für einen abgebrochenen Entwicklungsbuild entsprechend `automation/dev-build-lo
|
|
|
|
|
|
|
|
|
|
## Selfhosting und Updates
|
|
|
|
|
|
|
|
|
|
Für eine Installation eines bereits veröffentlichten Releases, hier beispielhaft `1.0.0`:
|
|
|
|
|
Für eine Installation eines bereits veröffentlichten Releases, hier beispielhaft `3.0.0`:
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
curl -fsSL https://git.federspiel.tech/flfeders/FEDEO/releases/download/v1.0.0/selfhost-install.sh -o /tmp/fedeo-install.sh
|
|
|
|
|
curl -fsSL https://git.federspiel.tech/flfeders/FEDEO/releases/download/v3.0.0/selfhost-install.sh -o /tmp/fedeo-install.sh
|
|
|
|
|
bash /tmp/fedeo-install.sh --simple --start
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Dieser versionierte Installer lädt die Betriebsdateien vom zugehörigen Git-Tag und schreibt `FEDEO_VERSION=1.0.0` in die neue `.env`. Vorhandene Installationen behalten ihren bisherigen Kanal, bis `FEDEO_VERSION` bewusst geändert wird. Die Dateien im Entwicklungszweig verwenden weiterhin `dev` als Rückfallwert.
|
|
|
|
|
Dieser versionierte Installer lädt die Betriebsdateien vom zugehörigen Git-Tag und schreibt `FEDEO_VERSION=3.0.0` in die neue `.env`. Vorhandene Installationen behalten ihren bisherigen Kanal, bis `FEDEO_VERSION` bewusst geändert wird. Die Dateien im Entwicklungszweig verwenden weiterhin `dev` als Rückfallwert.
|
|
|
|
|
|
|
|
|
|
Bei einem Update:
|
|
|
|
|
|
|
|
|
|
1. Release Notes und Migrationshinweise lesen. Konsistentes Datenbankbackup (z. B. `pg_dump`) sowie Datei-/Objektspeicher und Konfiguration sichern. Ein TAR des laufenden PostgreSQL-Datenverzeichnisses ist kein verlässliches Datenbankbackup.
|
|
|
|
|
2. Die benötigten Betriebsdateien vom gewünschten Release herunterladen; bestehende `.env` und Daten behalten. Downloads mit dessen `SHA256SUMS` überprüfen.
|
|
|
|
|
3. In `/opt/fedeo/.env` die feste Zielversion setzen, z. B. `FEDEO_VERSION=1.2.0`.
|
|
|
|
|
3. In `/opt/fedeo/.env` die feste Zielversion setzen, z. B. `FEDEO_VERSION=3.2.0`.
|
|
|
|
|
4. Images laden und Dienste neu erstellen:
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|