ScarriffleandClaude Opus 5
3df873c8cd
Der Runner auf dem NAS scheitert an der Docker-App des UGREEN: sie lehnt den Einhängepunkt /var/run/docker.sock ab. Nachgewiesen durch Halbieren der Compose-Datei — ohne diese eine Zeile wird das Projekt angelegt, mit ihr nicht, und die Meldung nennt keinen Grund. Übrig blieben Docker-in-Docker mit privileged oder der Weg über SSH an der Oberfläche vorbei. Beide geben dem Runner faktisch Root auf dem NAS, und das für eine Aufgabe, die der Arbeitsrechner ohnehin erledigen kann: er ist für die Apps nötig, weil Xcode nirgendwo sonst läuft. Der Workflow löst deshalb nicht mehr bei jedem Push aus. Sonst sammelt Gitea Läufe an, die niemand abarbeitet, und die Actions-Seite füllt sich mit Leichen. Er bleibt als workflow_dispatch stehen, der Auslöser ist mit drei Zeilen wieder da. Die Anleitung stellt das Bauen vom Arbeitsrechner nach vorn und hält zwei Dinge fest, die beim Einrichten Zeit gekostet haben: die Docker-App zieht Images nicht selbst, und die Anmeldung an der Registry will ein Zugriffstoken statt des Kontopassworts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
61 lines
2.8 KiB
YAML
61 lines
2.8 KiB
YAML
# Ein Gitea-Runner auf dem NAS.
|
|
#
|
|
# **Nicht in Betrieb — und auf einem UGREEN-NAS nicht über die Docker-App
|
|
# anzulegen.** Deren Compose-Prüfung lehnt den Einhängepunkt
|
|
# `/var/run/docker.sock` ab. Nachgewiesen durch Halbieren: dieselbe Datei
|
|
# ohne diese eine Zeile wird angelegt, mit ihr kommt nur „Bitte überprüfen
|
|
# Sie die Konfigurationsinformationen", ohne Angabe eines Grundes.
|
|
#
|
|
# Was bliebe: `gitea/act_runner:latest-dind-rootless` mit `privileged: true`
|
|
# statt des Socket, oder die Datei über SSH ablegen und dort von Hand
|
|
# starten. Beides gibt dem Runner faktisch Root auf dem NAS, und bei einem
|
|
# öffentlichen Repo reicht dann unter Umständen ein fremder Pull Request,
|
|
# um Code darauf auszuführen. Deshalb baut bis auf Weiteres der
|
|
# Arbeitsrechner — siehe `Tools/image-veroeffentlichen.sh`.
|
|
#
|
|
# Die Datei bleibt liegen, damit der Weg beim nächsten Mal nicht noch
|
|
# einmal von vorn untersucht werden muss.
|
|
#
|
|
# **Wozu.** Gitea verteilt Arbeit nur, es baut nicht selbst. Ohne einen
|
|
# registrierten Runner legt es bei jedem Push einen Lauf an, der dann
|
|
# liegenbleibt. Mit diesem hier baut das NAS das Flaro-Image selbst und legt
|
|
# es in die Registry desselben Gitea — danach braucht es keinen Arbeits-
|
|
# rechner mehr.
|
|
#
|
|
# **Das Token holst du dir vorher:**
|
|
# Gitea → Repo → Einstellungen → Actions → Runner → Neuen Runner erstellen
|
|
#
|
|
# Ein Runner auf Organisations- oder Serverebene bedient alle Repos; das
|
|
# Token dafür steht in der jeweiligen Verwaltung.
|
|
|
|
services:
|
|
runner:
|
|
image: gitea/act_runner:latest
|
|
container_name: gitea-runner
|
|
restart: unless-stopped
|
|
|
|
environment:
|
|
- GITEA_INSTANCE_URL=https://git.scarriffle.com
|
|
# Hier das Token aus der Gitea-Oberfläche eintragen.
|
|
- GITEA_RUNNER_REGISTRATION_TOKEN=
|
|
- GITEA_RUNNER_NAME=nas
|
|
# **Welche Marken dieser Runner bedient.** `ubuntu-latest` ist die, die
|
|
# der Flaro-Workflow in `runs-on` nennt. Ohne diese Zeile meldet sich
|
|
# der Runner mit den Vorgaben an, und ein Lauf findet ihn womöglich
|
|
# nicht.
|
|
- GITEA_RUNNER_LABELS=ubuntu-latest:docker://catthehacker/ubuntu:act-latest
|
|
|
|
volumes:
|
|
# **Der Docker-Socket ist der Kern.** Der Runner baut nicht selbst,
|
|
# sondern lässt den Docker des NAS bauen. Ohne ihn scheitert jeder
|
|
# Schritt, der ein Image anfasst.
|
|
#
|
|
# Das ist zugleich die Abwägung: wer in diesen Container kommt, kann
|
|
# Docker auf dem NAS steuern. Deshalb gehört er nicht ins Internet und
|
|
# nimmt nur Arbeit von deinem eigenen Gitea an.
|
|
- /var/run/docker.sock:/var/run/docker.sock
|
|
# Anmeldung und Zwischenstände. Ohne dieses Volume meldet sich der
|
|
# Runner nach jedem Neustart neu an, und in der Liste sammeln sich
|
|
# Karteileichen.
|
|
- /volume4/CRITICAL/Docker/gitea-runner:/data
|