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>
2026-10-04 08:08:22 +02:00
parent f2b5ee633b
commit c12748e262
4 changed files with 191 additions and 19 deletions
@@ -0,0 +1,75 @@
 # Baut das Flaro-Image und legt es in die Registry dieses Gitea.
 #
 # **Warum hier und nicht auf dem Arbeitsrechner.** Ein Bau von Hand heisst:
 # jemand muss daran denken, muss die richtige Architektur angeben und muss
 # angemeldet sein. Hier passiert es bei jedem Push von selbst, immer für
 # beide Architekturen, und die Anmeldung besorgt Gitea.
 #
 # **Voraussetzung ist ein Runner.** Ohne einen registrierten Act-Runner
 # läuft diese Datei nie an — dann bleibt der Weg von Hand aus
 # `Tools/image-veroeffentlichen.sh`.
 name: Image bauen und veröffentlichen
 on:
  push:
    branches: [main]
    tags: ['v*']
  workflow_dispatch:
 jobs:
  image:
    runs-on: ubuntu-latest
    steps:
      - name: Quelltext holen
        uses: actions/checkout@v4
      # **buildx, nicht das eingebaute `docker build`.** Nur damit lassen
      # sich zwei Architekturen in einem Manifest ablegen; ohne das bekommt
      # ein Intel-NAS ein arm64-Image und meldet „exec format error".
      - name: buildx vorbereiten
        uses: docker/setup-buildx-action@v3
      - name: QEMU für die fremde Architektur
        uses: docker/setup-qemu-action@v3
      - name: An der Registry anmelden
        uses: docker/login-action@v3
        with:
          registry: ${{ vars.REGISTRY || 'git.scarriffle.com' }}
          username: ${{ gitea.actor }}
          password: ${{ secrets.GITEA_TOKEN }}
      - name: Marken bestimmen
        id: marken
        run: |
          REGISTRY="${{ vars.REGISTRY || 'git.scarriffle.com' }}"
          # Gitea verlangt Kleinbuchstaben im Pfad; der Besitzername kann
          # gross geschrieben sein.
          PFAD=$(echo "${{ gitea.repository }}" | tr '[:upper:]' '[:lower:]')
          BILD="$REGISTRY/$PFAD"
          MARKEN="$BILD:latest,$BILD:${GITHUB_SHA::7}"
          # Auf einem Git-Tag zusätzlich dessen Namen — damit sich eine
          # Fassung festnageln lässt, statt immer „latest" zu ziehen.
          if [ "${GITHUB_REF_TYPE}" = "tag" ]; then
            MARKEN="$MARKEN,$BILD:${GITHUB_REF_NAME#v}"
          fi
          echo "marken=$MARKEN" >> "$GITHUB_OUTPUT"
          echo "Gebaut wird: $MARKEN"
      - name: Bauen und hochladen
        uses: docker/build-push-action@v5
        with:
          context: .
          file: server/Dockerfile
          # **Beide Architekturen.** amd64 für die Intel-NAS, arm64 für
          # ARM-Geräte und für den Apple-Rechner.
          platforms: linux/amd64,linux/arm64
          push: true
          tags: ${{ steps.marken.outputs.marken }}
          # Zwischenergebnisse behalten: ohne das lädt jeder Lauf alle
          # Pakete neu, und ein Bau dauert statt zwei Minuten zwölf.
          cache-from: type=gha
          cache-to: type=gha,mode=max
@@ -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}"
@@ -49,38 +49,75 @@ Drei Wege. Der erste ist der bequemste, der zweite braucht keine Registry.
 Dein Gitea unter `git.scarriffle.com` bringt eine Container-Registry mit.
 Einmal einrichten, danach ist jedes Update ein `docker compose pull`.
-Auf dem Arbeitsrechner:
+#### A1 · Gitea baut selbst
 `.gitea/workflows/image.yml` liegt im Projekt. Bei jedem Push auf `main`
 baut Gitea das Image für **beide** Architekturen und legt es ab — ohne dass
 jemand daran denken muss, und ohne Anmeldung am Arbeitsrechner.
 **Voraussetzung ist ein registrierter Act-Runner.** Hat dein Gitea keinen,
 passiert nichts; dann gilt A2. Nachsehen unter
 *Einstellungen → Actions → Runner*. Ein Runner lässt sich als Container
 neben Gitea betreiben:
 ```bash
 docker run -d --restart unless-stopped --name gitea-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -e GITEA_INSTANCE_URL=https://git.scarriffle.com \
    -e GITEA_RUNNER_REGISTRATION_TOKEN=<Token aus den Einstellungen> \
    gitea/act_runner:latest
 ```
 #### A2 · Von Hand vom Arbeitsrechner
 Einmalig anmelden — das Passwort tippst du selbst ein:
 ```bash
 docker login git.scarriffle.com
 ```
 Danach genügt ein Befehl; er baut amd64 **und** arm64 und lädt hoch:
 ```bash
-cd ~/Projects_Coding/Flixy
+Tools/image-veroeffentlichen.sh
 docker buildx build --platform linux/amd64 \
    -f server/Dockerfile \
    -t git.scarriffle.com/scarriffle/flaro:latest \
    --push .
 ```
-`--push` lädt direkt hoch; ein getrenntes `docker push` entfällt.
+Mit einer Fassungsnummer, wenn du sie festnageln willst:
-Auf dem NAS dann in der Compose-Datei:
+```bash
 Tools/image-veroeffentlichen.sh 0.2.0
 ```
 #### A3 · Das Paket öffentlich stellen
 Sonst muss sich auch das NAS anmelden. In Gitea unter
 *dein Profil → Pakete → flaro → Einstellungen* auf öffentlich stellen. Der
 Quelltext ist ohnehin offen; das Image enthält nichts, was er nicht auch
 enthält.
 #### A4 · Die Registry im NAS eintragen
 In der Docker-App des UGREEN: **Repository → Zahnrad → Quellname des
 Images → Hinzufügen**. Dort stehen schon DockerHub und `ghcr.io`; daneben
 kommt:
 | Feld | Wert |
 |---|---|
 | Alias | `gitea` |
 | Link | `https://git.scarriffle.com/` |
 **Bestätigen** — danach findet die Suche in der Docker-App auch
 `scarriffle/flaro`. Ist das Paket privat, trägst du unter
 *Registierungseinstellungen* Benutzername und ein Gitea-Zugriffstoken ein
 (nicht dein Kontopasswort: ein Token lässt sich einzeln widerrufen, unter
 *Einstellungen → Anwendungen → Zugriffstoken*, Berechtigung `read:package`).
 In der Compose-Datei steht dann:
 ```yaml
 image: git.scarriffle.com/scarriffle/flaro:latest
 ```
 Ist das Paket in Gitea **privat**, muss sich auch das NAS anmelden:
 ```bash
 docker login git.scarriffle.com
 ```
 Einfacher ist, das Paket in Gitea auf öffentlich zu stellen — unter
 *Pakete → flaro → Einstellungen*. Der Quelltext ist ohnehin offen; das Image
 enthält nichts, was es nicht auch tut.
 ### Weg B — als Datei hochladen
 Ohne Registry, dafür bei jedem Update von Hand.
@@ -5,7 +5,9 @@
 services:
  flaro:
-    image: ghcr.io/scarriffle/flaro:latest
+    # Die Registry des eigenen Gitea. Wer woanders veröffentlicht, trägt
    # hier etwas anderes ein — siehe docs/NAS-EINRICHTEN.md.
    image: git.scarriffle.com/scarriffle/flaro:latest
    container_name: flaro
    restart: unless-stopped