# Gitea Actions

Zwei Workflows:

| Datei | Auslöser | Was passiert |
|---|---|---|
| `ci.yml` | jeder Push, jeder Pull Request | Backend: `ruff check`, `ruff format --check`, `pytest` gegen einen PostgreSQL-Dienst. Frontend: `npm ci`, `tsc --noEmit`, `eslint`, `vitest`, Bundle-Bau. |
| `build.yml` | Push auf `main`, Tags `v*` | Baut beide Images für `linux/amd64` und lädt sie in die Gitea-Registry. **Kein Deploy** – das Ausrollen erfolgt von Hand. |

## Anmeldung an der Registry

`build.yml` versucht die Anmeldung in dieser Reihenfolge:

1. das Repo-Secret **`REGISTRY_TOKEN`**, falls vorhanden,
2. sonst `GITEA_TOKEN` – den Token, den Gitea jedem Lauf automatisch mitgibt.

Damit läuft der Workflow im Normalfall ohne jede manuelle Einrichtung. Reicht
das Recht des automatischen Tokens auf der Instanz nicht aus, bricht der Schritt
mit `denied` oder `unauthorized` ab; dann das Secret von Hand anlegen:

| Name | Zweck | Woher |
|---|---|---|
| `REGISTRY_TOKEN` | Anmeldung an `git.menzel.center` zum Hochladen der Images | Gitea → Benutzereinstellungen → Applications → **Generate New Token**, bei *package* auf `Read and Write` |

Anlegen unter *Repository → Settings → Actions → Secrets → Add Secret*.

Als Benutzername verwendet der Workflow `${{ github.actor }}`, also den Auslöser
des Laufs. Dieser Benutzer braucht Schreibrecht auf die Pakete des Namensraums
`menzeljonas`.

> Fehlt beides, meldet der Schritt `::error::Password required` und es entsteht
> **kein Image** – `docker compose pull` läuft dann in ein `not found`.

## Erzeugte Tags

| Auslöser | Tags |
|---|---|
| Push auf `main` | `:main`, `:sha-<kurz>` |
| Tag `v1.2.3` | `:1.2.3`, `:1.2`, `:latest` |

Zusätzlich legt jeder Lauf ein `:buildcache`-Manifest ab. Es dient
ausschließlich dem Schichten-Cache und ist nicht zum Ausrollen gedacht.

## Voraussetzungen an den Runner

Der Runner muss Docker erreichen können (gemounteter Socket) und das Label
`ubuntu-latest` anbieten. Die vollständige Einrichtung steht in
[`../../docs/runner.md`](../../docs/runner.md).