Runner-Setup fuer Gitea Actions

act_runner auf dem VPS, steuert den Docker-Daemon des Hosts ueber den
Socket. Registrierung ueber die interne Adresse http://gitea:3000 im Netz
gitea-ci - die oeffentliche Domain ist aus Containern heraus nicht
erreichbar (NAT-Hairpin, host-gateway zusaetzlich von der Firewall
geblockt).

Bewusst nicht im Netz nginx-proxy-manager_default: der Runner spricht mit
Gitea, nicht mit dem Proxy.

.env und data/ bleiben aussen vor, beide enthalten Runner-Credentials.

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

README.md

@@ -0,0 +1,104 @@
+# gitea-runner
+
+Der CI-Runner fuer Gitea Actions auf dem VPS. Baut und deployt die Apps,
+sobald in einem Repo ein Tag `v*` gepusht wird.
+
+Die Konventionen fuer die Apps selbst stehen nicht hier, sondern in
+[deploy-kit](https://gitea.lucas-orth.de/lucas.orth/deploy-kit).
+
+## Aufbau
+
+```
+Tag-Push -> Gitea -> gitea-runner -> Job-Container -> Docker-Daemon des Hosts
+```
+
+Der Runner steuert den Docker-Daemon ueber `/var/run/docker.sock`. Er baut
+also nicht in sich selbst, sondern auf dem Host - deshalb laufen die
+gebauten Container ganz normal neben ihm.
+
+Zwei getrennte Netze:
+
+| Netz | Wer haengt drin |
+|---|---|
+| `gitea-ci` | Gitea, Runner, Job-Container |
+| `nginx-proxy-manager_default` | Proxy, alle App-Container |
+
+Der Runner hat im Proxy-Netz nichts verloren - er spricht mit Gitea, nicht
+mit dem Proxy.
+
+## Einrichtung
+
+### 1. Actions in Gitea aktivieren
+
+In der `app.ini`:
+
+```ini
+[actions]
+ENABLED = true
+```
+
+Ab Gitea 1.21 Default. Danach Gitea neu starten.
+
+### 2. Netz anlegen und Gitea daran haengen
+
+```bash
+docker network create gitea-ci
+```
+
+In **Gitea's** `docker-compose.yml` ergaenzen - beim Service und im
+`networks`-Block:
+
+```yaml
+services:
+  server:
+    networks:
+      - nginx-proxy-manager_default
+      - gitea-ci
+
+networks:
+  nginx-proxy-manager_default:
+    external: true
+  gitea-ci:
+    external: true
+```
+
+Das ist der Teil, der es dauerhaft macht. `docker network connect` von Hand
+waere beim naechsten Recreate von Gitea wieder weg.
+
+Dann in Gitea's Verzeichnis `docker compose up -d` und pruefen:
+
+```bash
+docker inspect -f '{{range $n,$v := .NetworkSettings.Networks}}{{$n}} {{end}}' gitea
+```
+
+Beide Netze muessen erscheinen.
+
+### 3. Runner registrieren
+
+Token holen: Gitea -> Site Administration -> Actions -> Runner ->
+"Create new Runner".
+
+```bash
+cp .env.example .env && nano .env
+docker compose up -d
+docker compose logs --tail 30 runner
+```
+
+`runner registered successfully` muss erscheinen, in Gitea steht der Runner
+danach als **Idle**.
+
+## Warum die interne Adresse
+
+`GITEA_INSTANCE_URL` zeigt auf `http://gitea:3000`, nicht auf die
+oeffentliche Domain. Gitea laeuft auf demselben Host: ein Container, der die
+oeffentliche IP anspricht, bekommt keine Antwort zurueck (NAT-Hairpin). Der
+Umweg ueber `host-gateway` scheitert zusaetzlich an der Firewall.
+
+Aus demselben Grund setzen die Workflows in `actions/checkout` den Input
+`github-server-url: http://gitea:3000` - sonst klont der Job-Container ueber
+die oeffentliche Domain und laeuft in denselben Timeout.
+
+## Nicht im Repo
+
+`.env` (Registration-Token) und `data/` (enthaelt `.runner` mit dem
+dauerhaften Runner-Token). Beides steht in `.gitignore`.