ci: Workflows für Gitea Actions

CI prüft bei jedem Push Typen, Tests und den Produktionsbuild — die Tests
laufen gegen eine echte PostgreSQL-Instanz, weil sie Abfragen und
Fortschrittsberechnungen prüfen, nicht Attrappen.

Der Release-Workflow zieht die Notizen aus releases/vX.Y.Z.md, derselben
Datei, die auch von Hand für ein Release taugt. So gibt es eine Quelle für
den Text, und der Ablauf funktioniert mit und ohne CI.

.gitea/workflows/ci.yml

@@ -0,0 +1,63 @@
+# Prüft jeden Push: Typen, Tests, Produktionsbuild.
+#
+# Die Tests brauchen eine echte PostgreSQL-Instanz — sie prüfen Abfragen und
+# Fortschrittsberechnungen gegen die Datenbank, nicht gegen Attrappen. Einen
+# TMDB-Schlüssel brauchen sie nicht: die TMDB-Antworten sind nachgebildet.
+
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  pruefen:
+    runs-on: ubuntu-latest
+
+    services:
+      postgres:
+        image: postgres:17-alpine
+        env:
+          POSTGRES_USER: flimmer
+          POSTGRES_PASSWORD: flimmer-ci
+          POSTGRES_DB: flimmer
+        options: >-
+          --health-cmd "pg_isready -U flimmer -d flimmer"
+          --health-interval 5s
+          --health-timeout 5s
+          --health-retries 12
+        ports:
+          - 5432:5432
+
+    env:
+      DATABASE_URL: postgresql://flimmer:flimmer-ci@localhost:5432/flimmer?schema=public
+      AUTH_SECRET: ci-geheimnis-0123456789abcdef0123456789abcdef
+      APP_URL: http://localhost:3000
+      TZ: Europe/Berlin
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          cache: npm
+
+      - name: Abhängigkeiten installieren
+        run: npm ci --no-audit --no-fund
+
+      - name: Prisma-Client erzeugen
+        run: npx prisma generate
+
+      - name: Schema einspielen
+        run: npx prisma migrate deploy
+
+      - name: Typen prüfen
+        run: npm run typecheck
+
+      - name: Tests
+        run: npm test
+
+      - name: Produktionsbuild
+        run: npx next build

.gitea/workflows/release.yml

@@ -0,0 +1,56 @@
+# Legt beim Pushen eines Versions-Tags automatisch das Release an.
+#
+# Die Notizen kommen aus releases/vX.Y.Z.md — derselben Datei, die auch von
+# Hand für ein Release taugt. So gibt es genau eine Quelle für den Text, und
+# der Ablauf funktioniert mit und ohne CI.
+
+name: Release
+
+on:
+  push:
+    tags:
+      - "v*.*.*"
+
+jobs:
+  veroeffentlichen:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Release-Notizen einsammeln
+        id: notes
+        run: |
+          VERSION="${GITHUB_REF_NAME#v}"
+          FILE="releases/${GITHUB_REF_NAME}.md"
+
+          if [ ! -f "$FILE" ]; then
+            echo "Es gibt keine $FILE — bitte anlegen, bevor der Tag gepusht wird." >&2
+            exit 1
+          fi
+
+          # Die Überschrift der Datei ist der Titel; alles darunter der Text.
+          {
+            echo "version=$VERSION"
+            echo "body<<FLIMMER_EOF"
+            tail -n +2 "$FILE"
+            echo "FLIMMER_EOF"
+          } >> "$GITHUB_OUTPUT"
+
+      - name: Release anlegen
+        env:
+          TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          BODY: ${{ steps.notes.outputs.body }}
+          VERSION: ${{ steps.notes.outputs.version }}
+        run: |
+          PAYLOAD=$(jq -n \
+            --arg tag "$GITHUB_REF_NAME" \
+            --arg name "$VERSION" \
+            --arg body "$BODY" \
+            '{tag_name: $tag, name: $name, body: $body, draft: false, prerelease: false}')
+
+          curl -sSf -X POST \
+            -H "Authorization: token $TOKEN" \
+            -H "Content-Type: application/json" \
+            -d "$PAYLOAD" \
+            "$GITHUB_SERVER_URL/api/v1/repos/$GITHUB_REPOSITORY/releases"