# 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`.