From c8f11e0642f3b5905e9ad0322db1447ac703d1e0 Mon Sep 17 00:00:00 2001 From: Stefan Date: Sat, 29 Aug 2026 21:29:21 +0200 Subject: [PATCH] =?UTF-8?q?Bauen=20=C3=BCber=20Gitea=20Actions=20in=20die?= =?UTF-8?q?=20Roadmap=20aufnehmen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fehlte in Phase 4: das Image soll wie bei der Kantone-App über einen Versions-Tag gebaut, vor dem Veröffentlichen getestet und in die Gitea- Registry gestellt werden. Der Plan hält dazu die Punkte fest, die dort nachträglich korrigiert werden mussten - vor allem, Werte aus ${{ ... }} nicht direkt in die Shell zu schreiben, weil Tag-Namen Sonderzeichen enthalten dürfen und der Job ein Registry-Token hält. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01GR4bNaj9GtRu57J4Niii8o --- Plan.md | 35 +++++++++++++++++++++++++++++++++++ projekt.md | 4 ++++ 2 files changed, 39 insertions(+) diff --git a/Plan.md b/Plan.md index a2df5f4..21fff31 100644 --- a/Plan.md +++ b/Plan.md @@ -200,8 +200,43 @@ Die Phasen aus `projekt.md`, ergänzt um Tests und die Absicherung. **Phase 5 – Betrieb** - `Dockerfile` (Tailwind-Build inbegriffen), `docker-compose.yml`, Volumes - Healthcheck, Backup-Hinweise für Datenbank und Bilder +- **Gitea Actions**: Image bauen und in die Registry stellen (siehe unten) +- Zwei Compose-Dateien wie bei der Kantone-App: eine zum Selberbauen aus dem + Quellcode, eine zum blossen Starten des fertigen Images - README für Einrichtung und Reverse-Proxy +### Bauen über Gitea Actions + +Gleiches Vorgehen wie bei der Kantone-App +(`.gitea/workflows/docker-image.yml` dort als Vorlage): + +- **Auslöser:** nur ein Versions-Tag (`v*`) oder ein manueller Start + (`workflow_dispatch`) – **nicht** jeder Push auf `main`. Dadurch bleibt das + Zusammenführen von Branches folgenlos, und ein Release ist ein bewusster + Schritt. +- **Registry:** `gitea.boing86.myds.me`, Image `docker/kleiderboerse`. +- **Version:** aus dem Tag (`v1.2.3` → `1.2.3`), bei manuellen Läufen ein + Zeitstempel. Tag und Commit werden als Build-Argumente durchgereicht und in + der Fusszeile angezeigt – so ist sofort erkennbar, welcher Stand läuft. +- **Test vor der Veröffentlichung:** Container starten und prüfen, bevor + irgendetwas in die Registry geht. Bei der Kantone-App wird die API auf + 26 Kantone geprüft; hier wären die Entsprechungen: Startseite antwortet mit + 200, `/api/v1/categories` liefert die vorbefüllten Kategorien, und ein + Testupload wird tatsächlich als WebP abgelegt. Schlägt das fehl, wird nichts + veröffentlicht. +- **`latest`** nur für echte Versions-Tags, nicht für manuelle Läufe. +- **Anmeldung** über `--password-stdin` (das Token taucht so weder in der + Prozessliste noch im Protokoll auf), `docker logout` mit `if: always()`. + Zugangsdaten als Repo-Secrets (`REGISTRY_TOKEN`, `REGISTRY_USER`), nicht im + Workflow. +- **Rechte** im Job auf `contents: read` und `packages: write` begrenzen. +- **Werte aus `${{ ... }}` nie direkt in die Shell schreiben**, sondern über + `env:` durchreichen. Ausdrücke werden vor der Shell ersetzt, und Tag-Namen + dürfen Zeichen wie `"` oder `$` enthalten – sonst lässt sich über einen + präparierten Tag Code auf dem Runner ausführen, in einem Job, der ein + Registry-Token hält. (Genau das wurde in der Kantone-App nachträglich + korrigiert.) + --- ## Offene Punkte diff --git a/projekt.md b/projekt.md index 48a5cf2..534c2da 100644 --- a/projekt.md +++ b/projekt.md @@ -127,3 +127,7 @@ kinderkleider-app/ - [ ] **Phase 4: Containerisierung & Deployment** - [ ] `Dockerfile` & `docker-compose.yml` schreiben - [ ] Persistence per Volume-Mount für Datenbank & Bild-Uploads + - [ ] Gitea Actions: Image bei einem Versions-Tag (`v*`) bauen, testen und in + die Registry stellen — gleiches Vorgehen wie bei der Kantone-App + (`.gitea/workflows/docker-image.yml` dort als Vorlage) + - [ ] Zweite Compose-Datei zum Starten des fertigen Images (ohne Quellcode)