Ein Weg vom Quelltext in die Registry — und von dort aufs NAS

Damit das Image dort landet, wo das NAS es holen kann.

**`.gitea/workflows/image.yml`** — Gitea baut selbst. Bei jedem Push auf
`main` entsteht das Image für **beide** Architekturen und landet in der
Registry desselben Gitea. Niemand muss daran denken, niemand muss angemeldet
sein, und niemand kann die Architektur vergessen.

Voraussetzung ist ein registrierter Act-Runner. Hat deiner keinen, läuft die
Datei nie an — dafür gibt es den zweiten Weg.

**`Tools/image-veroeffentlichen.sh`** — ein Befehl vom Arbeitsrechner, baut
amd64 und arm64 und lädt hoch. Angemeldet wird einmalig von Hand; das
Passwort tippt nur, wer es kennt.

Beides legt `:latest` ab, dazu den Kurz-Hash und auf einem Git-Tag dessen
Namen — damit sich eine Fassung festnageln lässt, statt immer „latest" zu
ziehen.

Die Anleitung bekommt vier neue Abschnitte: Gitea baut selbst, von Hand
bauen, das Paket öffentlich stellen, und **die Registry im NAS eintragen** —
also genau der Dialog „Quellname des Images", mit Alias `gitea` und Link
`https://git.scarriffle.com/`. Für ein privates Paket ein Zugriffstoken mit
`read:package`, nicht das Kontopasswort: ein Token lässt sich einzeln
widerrufen.

Die Beispiel-Compose zeigte auf `ghcr.io/scarriffle/flaro` — dort liegt
nichts und lag nie etwas. Jetzt auf die Gitea-Registry.

---

**Ein Fehler im eigenen Skript, gefunden beim ersten Lauf.** Die Prüfung
„läuft Docker?" war `docker info | grep -q .` — und `grep -q` beendet die
Pipe beim ersten Treffer, Docker bekommt SIGPIPE, und mit `set -o pipefail`
gilt das als Fehlschlag. Das Skript meldete „Docker läuft nicht", während
Docker lief und gerade ein Image gebaut hatte.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Tools/image-veroeffentlichen.sh

@@ -0,0 +1,58 @@
+#!/bin/bash
+# Baut das Flaro-Image für beide Architekturen und legt es in die Registry.
+#
+# **Der Weg von Hand** — für den Fall, dass kein Gitea-Runner läuft. Sonst
+# macht das `.gitea/workflows/image.yml` bei jedem Push von selbst.
+#
+#   Tools/image-veroeffentlichen.sh              → :latest
+#   Tools/image-veroeffentlichen.sh 0.2.0        → :latest und :0.2.0
+#
+# Vorher einmalig anmelden — das Passwort tippst du selbst ein:
+#
+#   docker login git.scarriffle.com
+
+set -euo pipefail
+
+REGISTRY="${FLARO_REGISTRY:-git.scarriffle.com}"
+PFAD="${FLARO_IMAGE_PATH:-scarriffle/flaro}"
+BILD="$REGISTRY/$PFAD"
+FASSUNG="${1:-}"
+
+cd "$(dirname "$0")/.."
+
+command -v docker >/dev/null || { echo "docker fehlt."; exit 1; }
+
+# **Ohne Anmeldung bricht der Push erst nach dem ganzen Bau ab.** Zwei
+# Minuten Arbeit für eine Fehlermeldung, die am Anfang gestanden hätte.
+# Kein `docker info | grep -q`: `grep -q` beendet die Pipe beim ersten
+# Treffer, Docker bekommt SIGPIPE, und mit `set -o pipefail` gilt das als
+# Fehlschlag. Die Prüfung meldete dann „Docker läuft nicht", während es lief.
+if ! docker info >/dev/null 2>&1; then
+  echo "Docker läuft nicht."; exit 1
+fi
+if ! grep -q "$REGISTRY" ~/.docker/config.json 2>/dev/null; then
+  echo "Nicht an $REGISTRY angemeldet. Erst:"
+  echo
+  echo "    docker login $REGISTRY"
+  exit 1
+fi
+
+MARKEN=(-t "$BILD:latest")
+[ -n "$FASSUNG" ] && MARKEN+=(-t "$BILD:$FASSUNG")
+
+# **Ein eigener Builder.** Der Vorgabe-Builder von Docker Desktop kann kein
+# Manifest mit zwei Architekturen bauen; `docker buildx create` schon.
+docker buildx inspect flaro-bauer >/dev/null 2>&1 \
+  || docker buildx create --name flaro-bauer --use >/dev/null
+
+echo "Baue $BILD für amd64 und arm64 — das dauert, arm64 läuft unter Emulation."
+docker buildx build \
+  --builder flaro-bauer \
+  --platform linux/amd64,linux/arm64 \
+  -f server/Dockerfile \
+  "${MARKEN[@]}" \
+  --push .
+
+echo
+echo "Fertig. Auf dem NAS:"
+echo "    image: $BILD:${FASSUNG:-latest}"