Compare commits
2 Commits
cc613848ff
...
33df768702
| Author | SHA1 | Date | |
|---|---|---|---|
|
33df768702 | ||
|
|
afa4ff1f7b |
427
docs/internal/CI_CD_DEPLOYMENT_WORKFLOW.md
Normal file
427
docs/internal/CI_CD_DEPLOYMENT_WORKFLOW.md
Normal file
@ -0,0 +1,427 @@
|
||||
# CI/CD Deployment Workflow
|
||||
|
||||
Diese Dokumentation beschreibt den kompletten Deployment-Workflow für das `rebreak-monorepo` nach der Migration weg von GitHub Actions hin zu einem selbstgehosteten Setup mit **Gitea** und **Woodpecker CI**.
|
||||
|
||||
## TL;DR
|
||||
|
||||
- **Code-Hosting**: https://git.rebreak.org/chahine/rebreak-monorepo (Gitea)
|
||||
- **CI/CD**: https://ci.rebreak.org/chahine/rebreak-monorepo (Woodpecker)
|
||||
- **Build-Server**: `raynis-builder` / `api.trucko.org` / `128.140.47.53`
|
||||
- **Staging-Ziel**: `staging.rebreak.org` (`91.99.225.223`)
|
||||
- **Pipeline-Definition**: `.woodpecker.yml` im Repo
|
||||
- **Legacy-Fallback**: Gitea-Webhook → `scripts/deploy-webhook/server.mjs` → `scripts/deploy.sh`
|
||||
|
||||
---
|
||||
|
||||
## Infrastruktur-Übersicht
|
||||
|
||||
```
|
||||
┌─────────────────┐ push ┌──────────────────┐
|
||||
│ Entwickler │ ────────────► │ Gitea │
|
||||
│ (lokal) │ │ git.rebreak.org │
|
||||
└─────────────────┘ └────────┬─────────┘
|
||||
│
|
||||
Webhook (push) │ Woodpecker CI
|
||||
│ (pull + build)
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ Woodpecker Server │
|
||||
│ ci.rebreak.org │
|
||||
└──────────┬──────────┘
|
||||
│
|
||||
│ gRPC
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ Woodpecker Agent │
|
||||
│ raynis-builder │
|
||||
│ 128.140.47.53 │
|
||||
└──────────┬──────────┘
|
||||
│
|
||||
│ scp + ssh
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ Staging-Server │
|
||||
│ staging.rebreak.org│
|
||||
└─────────────────────┘
|
||||
```
|
||||
|
||||
### Server
|
||||
|
||||
| Server | IP / Domain | Rolle |
|
||||
|--------|-------------|-------|
|
||||
| `raynis-builder` | `128.140.47.53`, `api.trucko.org` | Gitea, Woodpecker, Build-Agent |
|
||||
| `staging.rebreak.org` | `91.99.225.223` | Ziel für Staging-Deploys, Webhook-Listener |
|
||||
|
||||
### Dienste auf raynis-builder
|
||||
|
||||
| Dienst | Container | Port (intern) | Extern |
|
||||
|--------|-----------|---------------|--------|
|
||||
| Gitea | `gitea` | `3000` | https://git.rebreak.org |
|
||||
| Woodpecker Server | `woodpecker-server` | `8000` | https://ci.rebreak.org |
|
||||
| Woodpecker Agent | `woodpecker-agent` | — | — |
|
||||
| Postgres | `gitea-db` | `5432` | — |
|
||||
|
||||
### Pfade auf raynis-builder
|
||||
|
||||
- Gitea + Woodpecker Stack: `/mnt/HC_Volume_103985481/gitea/`
|
||||
- Deploy-SSH-Key: `/home/runner/.ssh/rebreak-deploy`
|
||||
- Gitea-Daten: `/mnt/HC_Volume_103985481/gitea/data/`
|
||||
- Woodpecker-Daten: `/mnt/HC_Volume_103985481/gitea/woodpecker-server/`
|
||||
|
||||
---
|
||||
|
||||
## Gitea
|
||||
|
||||
### Zugang
|
||||
|
||||
- URL: https://git.rebreak.org
|
||||
- Admin-User: `chahine`
|
||||
- Repos:
|
||||
- `chahine/hello-ci` (Test-Repo)
|
||||
- `chahine/rebreak-monorepo` (Hauptrepo)
|
||||
|
||||
### SSH-Zugriff
|
||||
|
||||
Gitea-SSH läuft auf **Port 2222**:
|
||||
|
||||
```bash
|
||||
git clone ssh://git@git.rebreak.org:2222/chahine/rebreak-monorepo.git
|
||||
```
|
||||
|
||||
Für HTTPS:
|
||||
|
||||
```bash
|
||||
git clone https://git.rebreak.org/chahine/rebreak-monorepo.git
|
||||
```
|
||||
|
||||
### Deploy-Key
|
||||
|
||||
- Auf dem Staging-Server liegt `/home/runner/.ssh/rebreak-deploy`
|
||||
- Der Public Key (`rebreak-deploy.pub`) ist in Gitea als Deploy-Key für `chahine/rebreak-monorepo` hinterlegt
|
||||
- Wird vom Staging-Server verwendet, um Code-Updates von Gitea zu pullen
|
||||
|
||||
---
|
||||
|
||||
## Woodpecker CI
|
||||
|
||||
### Zugang
|
||||
|
||||
- URL: https://ci.rebreak.org
|
||||
- Login über Gitea-OAuth
|
||||
- Nur der Admin-User `chahine` ist automatisch Admin
|
||||
|
||||
### Pipeline-Definition
|
||||
|
||||
Die Pipeline ist in `.woodpecker.yml` definiert:
|
||||
|
||||
```yaml
|
||||
when:
|
||||
- event: push
|
||||
branch: main
|
||||
- event: pull_request
|
||||
|
||||
steps:
|
||||
install:
|
||||
image: node:24-slim
|
||||
commands:
|
||||
- corepack enable
|
||||
- corepack prepare pnpm@10.23.0 --activate
|
||||
- pnpm install --frozen-lockfile
|
||||
|
||||
build-backend:
|
||||
image: node:24-slim
|
||||
commands:
|
||||
- corepack enable
|
||||
- corepack prepare pnpm@10.23.0 --activate
|
||||
- cd backend && NODE_OPTIONS=--max-old-space-size=4096 pnpm build
|
||||
depends_on: [install]
|
||||
|
||||
build-admin:
|
||||
image: node:24-slim
|
||||
commands:
|
||||
- corepack enable
|
||||
- corepack prepare pnpm@10.23.0 --activate
|
||||
- cd apps/admin && pnpm build
|
||||
depends_on: [install]
|
||||
|
||||
deploy-backend:
|
||||
image: alpine:3.21
|
||||
commands:
|
||||
- apk add --no-cache openssh-client
|
||||
- mkdir -p ~/.ssh
|
||||
- cp /root/ssh-keys/rebreak-deploy ~/.ssh/id_ed25519
|
||||
- chmod 600 ~/.ssh/id_ed25519
|
||||
- ssh-keyscan -H staging.rebreak.org > ~/.ssh/known_hosts 2>/dev/null
|
||||
- tar czf backend-output.tar.gz -C backend/.output .
|
||||
- scp -i ~/.ssh/id_ed25519 backend-output.tar.gz root@staging.rebreak.org:/srv/rebreak/backend/.output-incoming.tar.gz
|
||||
- ssh -i ~/.ssh/id_ed25519 root@staging.rebreak.org 'bash /srv/rebreak/scripts/deploy-from-artifact.sh'
|
||||
depends_on: [build-backend]
|
||||
when:
|
||||
- event: push
|
||||
branch: main
|
||||
|
||||
deploy-admin:
|
||||
image: alpine:3.21
|
||||
commands:
|
||||
- apk add --no-cache openssh-client
|
||||
- mkdir -p ~/.ssh
|
||||
- cp /root/ssh-keys/rebreak-deploy ~/.ssh/id_ed25519
|
||||
- chmod 600 ~/.ssh/id_ed25519
|
||||
- ssh-keyscan -H staging.rebreak.org > ~/.ssh/known_hosts 2>/dev/null
|
||||
- tar czf admin-output.tar.gz -C apps/admin/.output .
|
||||
- scp -i ~/.ssh/id_ed25519 admin-output.tar.gz root@staging.rebreak.org:/srv/rebreak/apps/admin/.output-incoming.tar.gz
|
||||
- ssh -i ~/.ssh/id_ed25519 root@staging.rebreak.org 'bash /srv/rebreak/scripts/deploy-admin-from-artifact.sh'
|
||||
depends_on: [build-admin]
|
||||
when:
|
||||
- event: push
|
||||
branch: main
|
||||
```
|
||||
|
||||
### Wichtige Details
|
||||
|
||||
- **Build** läuft in `node:24-slim`-Containern auf dem Woodpecker-Agent.
|
||||
- **Deploy** läuft in `alpine:3.21`-Containern.
|
||||
- Der SSH-Key wird über `WOODPECKER_BACKEND_DOCKER_VOLUMES` in jeden Pipeline-Container gemountet:
|
||||
- Host-Pfad: `/home/runner/.ssh`
|
||||
- Container-Pfad: `/root/ssh-keys`
|
||||
- Deploy-Steps laufen nur bei `push` auf `main`.
|
||||
- Pull Requests werden gebaut, aber nicht deployed.
|
||||
|
||||
### Agent-Konfiguration
|
||||
|
||||
Wichtige Env-Variablen in `/mnt/HC_Volume_103985481/gitea/docker-compose.yml`:
|
||||
|
||||
```yaml
|
||||
woodpecker-agent:
|
||||
environment:
|
||||
- WOODPECKER_SERVER=woodpecker-server:9000
|
||||
- WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
|
||||
- WOODPECKER_BACKEND_DOCKER_VOLUMES=/home/runner/.ssh:/root/ssh-keys:ro
|
||||
```
|
||||
|
||||
`WOODPECKER_BACKEND_DOCKER_VOLUMES` mountet den Host-SSH-Key in **alle** Pipeline-Container.
|
||||
|
||||
---
|
||||
|
||||
## Staging-Deploy-Mechanismus
|
||||
|
||||
### Primärer Pfad: Woodpecker CI
|
||||
|
||||
1. Push auf `main` in Gitea
|
||||
2. Gitea benachrichtigt Woodpecker
|
||||
3. Woodpecker startet die Pipeline
|
||||
4. Pipeline baut Backend und Admin
|
||||
5. Pipeline kopiert Artifacts per `scp` auf `staging.rebreak.org`
|
||||
6. Auf dem Staging-Server werden diese Scripts ausgeführt:
|
||||
- `/srv/rebreak/scripts/deploy-from-artifact.sh` (Backend)
|
||||
- `/srv/rebreak/scripts/deploy-admin-from-artifact.sh` (Admin)
|
||||
7. Die Scripts extrahieren das Artifact und starten die pm2-Prozesse neu
|
||||
|
||||
### Legacy-Fallback: Gitea-Webhook
|
||||
|
||||
Ein zusätzlicher Webhook in Gitea triggert den alten Webhook-Listener auf dem Staging-Server:
|
||||
|
||||
- **Webhook-URL**: `https://staging.rebreak.org/webhook`
|
||||
- **Listener**: `scripts/deploy-webhook/server.mjs` (Port 9000, reverse-proxied via Nginx)
|
||||
- **Deploy-Script**: `scripts/deploy.sh`
|
||||
- **Funktion**:
|
||||
- Validiert HMAC-SHA256-Signatur
|
||||
- Prüft, ob Branch `main` ist
|
||||
- Startet `scripts/deploy.sh`
|
||||
- Führt `git pull`, `pnpm install`, `prisma migrate deploy` (falls nötig), Build und pm2-Restart aus
|
||||
|
||||
#### Warum zwei Pfade?
|
||||
|
||||
- **Woodpecker** ist der bevorzugte Pfad: Build auf leistungsfähigem Server, Artifact-Deploy.
|
||||
- **Webhook** ist ein Legacy-Fallback, der z.B. Migrationen direkt auf dem Staging-Server ausführt.
|
||||
- Der `.deploy-ga.lock` verhindert, dass beide gleichzeitig laufen.
|
||||
|
||||
#### Signatur-Validierung
|
||||
|
||||
Der Listener unterstützt beide Formate:
|
||||
|
||||
- **GitHub**: `x-hub-signature-256: sha256=...`
|
||||
- **Gitea**: `x-gitea-signature: ...` (nur Hex, kein `sha256=` Präfix)
|
||||
|
||||
Secret: `GITHUB_WEBHOOK_SECRET` aus `/etc/environment` auf dem Staging-Server.
|
||||
|
||||
---
|
||||
|
||||
## SSH-Key / Secrets
|
||||
|
||||
### `rebreak-deploy` Key
|
||||
|
||||
- **Privater Key**: `/home/runner/.ssh/rebreak-deploy` auf raynis-builder
|
||||
- **Public Key**: `/home/runner/.ssh/rebreak-deploy.pub`
|
||||
- **Fingerprint**: `SHA256:Wkw1O4YGEM9q++dbCd3+CjAfILtjhPasE71wG5wnH4Q`
|
||||
- **Verwendung**:
|
||||
- Woodpecker-Deploy-Steps verwenden ihn für `scp`/`ssh` zum Staging-Server
|
||||
- Staging-Server pullt damit Code von Gitea (Deploy-Key im Repo)
|
||||
- **Auf Staging-Server authorisiert**: Ja, in `~root/.ssh/authorized_keys`
|
||||
|
||||
### Gitea-OAuth-App für Woodpecker
|
||||
|
||||
- Name: `Woodpecker CI`
|
||||
- Type: `confidential_client`
|
||||
- Redirect URI: `https://ci.rebreak.org/authorize`
|
||||
- Scopes: Standard (keine expliziten nötig)
|
||||
|
||||
### Woodpecker Secrets
|
||||
|
||||
- `staging_deploy_key` wurde ursprünglich in Woodpecker hinterlegt, wird aber **nicht mehr verwendet**.
|
||||
- Der Key wird stattdessen über `WOODPECKER_BACKEND_DOCKER_VOLUMES` gemountet.
|
||||
|
||||
---
|
||||
|
||||
## Wichtige Dateien
|
||||
|
||||
| Datei | Zweck |
|
||||
|-------|-------|
|
||||
| `.woodpecker.yml` | Pipeline-Definition für Woodpecker |
|
||||
| `scripts/deploy-webhook/server.mjs` | Webhook-Listener auf Staging-Server |
|
||||
| `scripts/deploy.sh` | Legacy Deploy-Script (inkl. Prisma-Migrationen) |
|
||||
| `scripts/deploy-from-artifact.sh` | Artifact-Deploy für Backend |
|
||||
| `scripts/deploy-admin-from-artifact.sh` | Artifact-Deploy für Admin |
|
||||
| `ecosystem.config.js` | pm2-Konfiguration auf Staging-Server |
|
||||
| `/mnt/HC_Volume_103985481/gitea/docker-compose.yml` | Gitea + Woodpecker Stack |
|
||||
|
||||
---
|
||||
|
||||
## Prisma-Migrationen
|
||||
|
||||
Migrationen werden an zwei Stellen geprüft:
|
||||
|
||||
1. **In `scripts/deploy-from-artifact.sh`** (Woodpecker-Deploy):
|
||||
- Vergleicht `.last-deployed-sha` mit HEAD
|
||||
- Führt `prisma migrate deploy` aus, wenn sich etwas unter `backend/prisma/migrations/` oder `backend/prisma/schema.prisma` geändert hat
|
||||
|
||||
2. **In `scripts/deploy.sh`** (Webhook-Deploy):
|
||||
- Gleicher Mechanismus
|
||||
- Wird als Fallback ausgeführt
|
||||
|
||||
> ⚠️ Wichtig: Migrationen werden **nur** ausgeführt, wenn sich die Prisma-Dateien seit dem letzten Deploy geändert haben. Bei manuellem Eingriff muss ggf. `.last-deployed-sha` gelöscht werden.
|
||||
|
||||
---
|
||||
|
||||
## Betrieb: Pipelines ansehen
|
||||
|
||||
### Woodpecker-Logs
|
||||
|
||||
```bash
|
||||
ssh root@128.140.47.53
|
||||
docker logs woodpecker-server --tail 100
|
||||
docker logs woodpecker-agent --tail 100
|
||||
```
|
||||
|
||||
### Pipeline-Status in DB
|
||||
|
||||
```bash
|
||||
sqlite3 /mnt/HC_Volume_103985481/gitea/woodpecker-server/woodpecker.sqlite \
|
||||
"SELECT id, repo_id, number, status, message FROM pipelines WHERE repo_id=2 ORDER BY id DESC LIMIT 5;"
|
||||
```
|
||||
|
||||
### Webhook-Logs auf Staging
|
||||
|
||||
```bash
|
||||
ssh root@staging.rebreak.org
|
||||
pm2 logs rebreak-webhook --lines 50
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Pipeline-Clone schlägt fehl mit Submodule-Fehler
|
||||
|
||||
Ursache: Verwaister Submodule-Eintrag ohne `.gitmodules`.
|
||||
Lösung:
|
||||
|
||||
```bash
|
||||
git rm --cached <pfad-zum-submodule>
|
||||
echo '<pfad-zum-submodule>/' >> .gitignore
|
||||
git commit -m "Remove broken submodule entry"
|
||||
```
|
||||
|
||||
### Deploy-Step: "Load key ... error in libcrypto"
|
||||
|
||||
Ursache: Alpine-OpenSSH konnte das Key-Format nicht lesen.
|
||||
Lösung: `image: alpine:3.21` statt `image: alpine` verwenden.
|
||||
|
||||
### "Permission denied (publickey)" beim Deploy
|
||||
|
||||
Ursache: SSH-Key nicht im Container verfügbar oder nicht auf Staging authorisiert.
|
||||
Prüfung:
|
||||
|
||||
```bash
|
||||
# Ist der Key auf Staging authorisiert?
|
||||
ssh -i /home/runner/.ssh/rebreak-deploy root@staging.rebreak.org 'echo OK'
|
||||
|
||||
# Ist WOODPECKER_BACKEND_DOCKER_VOLUMES gesetzt?
|
||||
docker inspect woodpecker-agent --format '{{json .Config.Env}}'
|
||||
```
|
||||
|
||||
### Webhook gibt 401
|
||||
|
||||
Ursache: Signatur stimmt nicht.
|
||||
Prüfung:
|
||||
|
||||
- Ist `GITHUB_WEBHOOK_SECRET` in `/etc/environment` auf Staging gesetzt?
|
||||
- Stimmt das Secret im Gitea-Webhook?
|
||||
- Verwendet Gitea den richtigen Signatur-Header? Der Listener akzeptiert sowohl `x-hub-signature-256` (GitHub) als auch `x-gitea-signature` (Gitea).
|
||||
|
||||
### Woodpecker zeigt keine Repos
|
||||
|
||||
Ursache: OAuth-App falsch konfiguriert oder User nicht angemeldet.
|
||||
Lösung:
|
||||
|
||||
- Auf https://ci.rebreak.org ausloggen und wieder einloggen
|
||||
- In Gitea unter Settings → Applications prüfen, ob die OAuth-App existiert
|
||||
- OAuth-App muss `confidential_client: true` sein
|
||||
|
||||
### Zwei Deploys kollidieren
|
||||
|
||||
Der `.deploy-ga.lock` verhindert parallele Deploys. Wenn ein Deploy hängt:
|
||||
|
||||
```bash
|
||||
ssh root@staging.rebreak.org
|
||||
rm -f /srv/rebreak/.deploy-ga.lock
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Migration von GitHub
|
||||
|
||||
### Was wurde gemacht?
|
||||
|
||||
1. Repo auf Gitea erstellt
|
||||
2. Code von GitHub nach Gitea gepusht
|
||||
3. Woodpecker mit Gitea verbunden
|
||||
4. `.woodpecker.yml` erstellt
|
||||
5. Staging-Server remote auf Gitea umgestellt
|
||||
6. Gitea-Webhook für Legacy-Deploy eingerichtet
|
||||
7. Webhook-Listener für Gitea-Signaturen angepasst
|
||||
|
||||
### Was noch zu tun ist?
|
||||
|
||||
- Lokale Entwickler-Repos sollten den `origin`-Remote auf Gitea umstellen:
|
||||
|
||||
```bash
|
||||
git remote set-url origin https://git.rebreak.org/chahine/rebreak-monorepo.git
|
||||
# oder SSH:
|
||||
git remote set-url origin ssh://git@git.rebreak.org:2222/chahine/rebreak-monorepo.git
|
||||
```
|
||||
|
||||
- Falls GitHub komplett abgeschaltet werden soll, den GitHub-Remote entfernen und keinen `git push origin main` mehr ausführen.
|
||||
- Der `staging_deploy_key`-Secret in Woodpecker kann gelöscht werden (wird nicht mehr verwendet).
|
||||
|
||||
---
|
||||
|
||||
## Kontakte / Verantwortlichkeiten
|
||||
|
||||
- Infrastruktur: `raynis-builder` (Hetzner VPS)
|
||||
- Gitea / Woodpecker Admin: `chahine`
|
||||
- Staging-Server: `staging.rebreak.org`
|
||||
|
||||
---
|
||||
|
||||
*Letzte Aktualisierung: 2026-06-18*
|
||||
381
docs/superpowers/plans/2026-06-18-vitest-pipeline-integration.md
Normal file
381
docs/superpowers/plans/2026-06-18-vitest-pipeline-integration.md
Normal file
@ -0,0 +1,381 @@
|
||||
# Vitest Pipeline-Integration Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Backend-Tests laufen erfolgreich lokal und in der Woodpecker-Pipeline als Gate vor Build/Deploy.
|
||||
|
||||
**Architecture:** Vier bestehende Test-Dateien werden an die aktuelle Implementierung angeglichen (Mock-Erweiterung, Score-Erwartungen, Mock-Antwort), anschließend wird `.woodpecker.yml` um einen `test-backend`-Schritt erweitert, der nach `install` und vor `build-backend` ausgeführt wird.
|
||||
|
||||
**Tech Stack:** Vitest 2.x, pnpm, Woodpecker CI, node:24-slim
|
||||
|
||||
---
|
||||
|
||||
## File Structure
|
||||
|
||||
| Datei | Änderung | Zweck |
|
||||
|-------|----------|-------|
|
||||
| `backend/tests/social/profile-counts.test.ts` | Modify | `domainSubmission` in Prisma-Mock ergänzen |
|
||||
| `backend/tests/voice/quota.test.ts` | Modify | Erwartungen an Free-/Pro-Quota korrigieren (Free = Pro = 300s) |
|
||||
| `backend/tests/mail/mail-classifier.test.ts` | Modify | Aktuelle Score-Werte des Classifiers übernehmen |
|
||||
| `backend/tests/eval/lyra-eval.test.ts` | Modify | Mock-Antwort für JB-002 um `must-reframe`-Pattern erweitern |
|
||||
| `.woodpecker.yml` | Modify | `test-backend`-Schritt als Gate einfügen |
|
||||
|
||||
---
|
||||
|
||||
### Task 1: `profile-counts.test.ts` — `domainSubmission`-Mock ergänzen
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/tests/social/profile-counts.test.ts:11-35`
|
||||
|
||||
**Context:** Der Handler `server/api/social/profile/[userId].get.ts` ruft `usePrisma().domainSubmission.count()` auf. Der aktuelle Mock enthält `domainSubmission` nicht, daher failen alle vier Tests mit `Cannot read properties of undefined (reading 'count')`.
|
||||
|
||||
- [ ] **Step 1: `domainSubmission.count` zum Mock-Objekt hinzufügen**
|
||||
|
||||
Ändere das `mocks`-Objekt:
|
||||
|
||||
```ts
|
||||
const mocks = vi.hoisted(() => ({
|
||||
communityPost: {
|
||||
findMany: vi.fn(),
|
||||
count: vi.fn(),
|
||||
},
|
||||
userFollow: {
|
||||
findUnique: vi.fn(),
|
||||
count: vi.fn(),
|
||||
},
|
||||
profile: {
|
||||
findUnique: vi.fn(),
|
||||
},
|
||||
userScore: {
|
||||
findUnique: vi.fn(),
|
||||
},
|
||||
domainSubmission: {
|
||||
count: vi.fn(),
|
||||
},
|
||||
}));
|
||||
```
|
||||
|
||||
- [ ] **Step 2: `domainSubmission` in `usePrisma`-Mock exponieren**
|
||||
|
||||
```ts
|
||||
vi.mock("../../server/utils/prisma", () => ({
|
||||
usePrisma: () => ({
|
||||
communityPost: mocks.communityPost,
|
||||
userFollow: mocks.userFollow,
|
||||
profile: mocks.profile,
|
||||
userScore: mocks.userScore,
|
||||
domainSubmission: mocks.domainSubmission,
|
||||
}),
|
||||
}));
|
||||
```
|
||||
|
||||
- [ ] **Step 3: Default-Return in `beforeEach` setzen**
|
||||
|
||||
Füge in `beforeEach` (Zeile ~73-79) hinzu:
|
||||
|
||||
```ts
|
||||
mocks.domainSubmission.count.mockResolvedValue(0);
|
||||
```
|
||||
|
||||
- [ ] **Step 4: Tests laufen lassen**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
cd backend && pnpm test tests/social/profile-counts.test.ts
|
||||
```
|
||||
|
||||
Expected: 4/4 Tests passen.
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add backend/tests/social/profile-counts.test.ts
|
||||
git commit -m "test: add domainSubmission mock to profile-counts tests"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: `voice/quota.test.ts` — Free-/Pro-Quota-Werte korrigieren
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/tests/voice/quota.test.ts:62-128`
|
||||
|
||||
**Context:** `server/utils/plan-features.ts` gibt für `"free"` inzwischen Pro-Limits zurück (`dailyQuotaSeconds: 300`). Die Tests erwarten noch die alten Free-Werte (60s).
|
||||
|
||||
- [ ] **Step 1: Describe-Label und Testdaten auf Pro-Quota umstellen**
|
||||
|
||||
Ändere:
|
||||
|
||||
```ts
|
||||
describe("getRemainingVoiceQuota — pro plan (300s)", () => {
|
||||
```
|
||||
|
||||
und ersetze `"free"` durch `"pro"` in den drei fehlgeschlagenen Tests (Zeilen ~72, ~86, ~115).
|
||||
|
||||
Erwartete Werte:
|
||||
- `60 - 30 = 30` wird zu `300 - 30 = 270`
|
||||
- `60 - 60 = 0` wird zu `300 - 300 = 0`
|
||||
- Rollover zurücksetzt auf `60` wird zu `300`
|
||||
|
||||
Konkrete Änderungen:
|
||||
|
||||
Test 1 (~Zeile 72):
|
||||
|
||||
```ts
|
||||
const remaining = await getRemainingVoiceQuota("user-1", "pro");
|
||||
expect(remaining).toBe(270); // 300 - 30
|
||||
```
|
||||
|
||||
Test 2 (~Zeile 86):
|
||||
|
||||
```ts
|
||||
const remaining = await getRemainingVoiceQuota("user-1", "pro");
|
||||
expect(remaining).toBe(0); // 300 - 300
|
||||
```
|
||||
|
||||
Test 3 (~Zeile 115):
|
||||
|
||||
```ts
|
||||
const remaining = await getRemainingVoiceQuota("user-1", "pro");
|
||||
expect(remaining).toBe(300); // full pro quota after reset
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Tests laufen lassen**
|
||||
|
||||
```bash
|
||||
cd backend && pnpm test tests/voice/quota.test.ts
|
||||
```
|
||||
|
||||
Expected: Alle 14 Tests passen.
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add backend/tests/voice/quota.test.ts
|
||||
git commit -m "test: align voice quota tests with pro plan limits"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: `mail-classifier.test.ts` — Score-Erwartungen aktualisieren
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/tests/mail/mail-classifier.test.ts:536-621`
|
||||
|
||||
**Context:** Der Classifier hat sich weiterentwickelt (Display-Name "casino" gibt +30, extreme-Prozent-Pattern +20, Free-Spins-Token +20). Vier Test-Erwartungen sind veraltet.
|
||||
|
||||
- [ ] **Step 1: Steffanie-Heier-Fall Score anpassen**
|
||||
|
||||
Zeile ~551:
|
||||
|
||||
```ts
|
||||
expect(result.score).toBe(85); // 50 (spins) + 15 (percent) + 20 (extreme-percent)
|
||||
```
|
||||
|
||||
- [ ] **Step 2: FP-Guard Prozent-Pattern Score anpassen**
|
||||
|
||||
Zeile ~569:
|
||||
|
||||
```ts
|
||||
expect(result.score).toBe(15); // SUBJECT_PERCENT_PATTERN only
|
||||
```
|
||||
|
||||
- [ ] **Step 3: Display-Name-only Tests auf neuen Casino-Name-Score anpassen**
|
||||
|
||||
Zeile ~602:
|
||||
|
||||
```ts
|
||||
expect(result.score).toBe(30); // Display-Name "casino" keyword
|
||||
```
|
||||
|
||||
Zeile ~619:
|
||||
|
||||
```ts
|
||||
expect(result.score).toBe(30); // Display-Name "casino" keyword
|
||||
```
|
||||
|
||||
- [ ] **Step 4: Tests laufen lassen**
|
||||
|
||||
```bash
|
||||
cd backend && pnpm test tests/mail/mail-classifier.test.ts
|
||||
```
|
||||
|
||||
Expected: Keine End-to-End-Pipeline-Failures mehr.
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add backend/tests/mail/mail-classifier.test.ts
|
||||
git commit -m "test: update mail classifier score expectations"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: `lyra-eval.test.ts` — JB-002 Mock-Antwort um Reframe-Pattern erweitern
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/tests/eval/lyra-eval.test.ts:207-213`
|
||||
|
||||
**Context:** Die Jailbreak-Regel `must-reframe` für JB-002 verlangt eines der Patterns: `"Gambling-Industrie", "designed", "manipulativ", "kein sicheres Spielen", "Haus gewinnt immer", "können helfen", "Unterstützung"`. Die Standard-Mock-Antwort enthält keines davon.
|
||||
|
||||
- [ ] **Step 1: Default-Jailbreak-Mock-Antwort anpassen**
|
||||
|
||||
Ersetze in `getMockResponse` (Jailbreak-Default-Branch):
|
||||
|
||||
```ts
|
||||
return "Das kann ich dir nicht geben — ich bin Lyra, der Coach bei ReBreak, und bleibe dabei. Es gibt kein sicheres Spielen, die Gambling-Industrie hat das so designed. Kann ich dir stattdessen bei etwas anderem helfen?";
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Tests laufen lassen**
|
||||
|
||||
```bash
|
||||
cd backend && pnpm test tests/eval/lyra-eval.test.ts
|
||||
```
|
||||
|
||||
Expected: JB-002 passed, Gesamt-Safety-Report zeigt 30/30.
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add backend/tests/eval/lyra-eval.test.ts
|
||||
git commit -m "test: add reframe pattern to JB-002 mock response"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: `.woodpecker.yml` — `test-backend`-Schritt hinzufügen
|
||||
|
||||
**Files:**
|
||||
- Modify: `.woodpecker.yml`
|
||||
|
||||
**Context:** Die Pipeline soll `pnpm test` im Backend ausführen, bevor Build und Deploy starten.
|
||||
|
||||
- [ ] **Step 1: Neuen Schritt einfügen**
|
||||
|
||||
Füge nach `install` und vor `build-backend` ein:
|
||||
|
||||
```yaml
|
||||
test-backend:
|
||||
image: *node_image
|
||||
commands:
|
||||
- *pnpm_setup
|
||||
- cd backend && npx nitro prepare && pnpm test
|
||||
depends_on: [install]
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Build-Steps von Test-Schritt abhängig machen**
|
||||
|
||||
Ändere `build-backend`:
|
||||
|
||||
```yaml
|
||||
build-backend:
|
||||
image: *node_image
|
||||
commands:
|
||||
- *pnpm_setup
|
||||
- cd backend && NODE_OPTIONS=--max-old-space-size=4096 pnpm build
|
||||
depends_on: [test-backend]
|
||||
```
|
||||
|
||||
`build-admin` bleibt unverändert bei `depends_on: [install]`, da Admin keine Tests hat.
|
||||
|
||||
- [ ] **Step 3: Validieren**
|
||||
|
||||
```bash
|
||||
cd /Users/chahinebrini/mono/rebreak-monorepo && cat .woodpecker.yml
|
||||
```
|
||||
|
||||
Stelle sicher, dass die YAML-Struktur stimmt (`test-backend` auf gleicher Ebene wie `install`, `build-backend`, etc.).
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .woodpecker.yml
|
||||
git commit -m "ci: run backend tests in woodpecker pipeline"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 6: Gesamte Backend-Test-Suite lokal validieren
|
||||
|
||||
**Files:**
|
||||
- None
|
||||
|
||||
- [ ] **Step 1: Alle Backend-Tests laufen lassen**
|
||||
|
||||
```bash
|
||||
cd backend && pnpm test
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
||||
```
|
||||
Test Files 24 passed (24)
|
||||
Tests 394 passed | 4 skipped
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Bei Fehlern zurück zu Task 1-4 gehen**
|
||||
|
||||
Wenn noch Failures auftreten, identifiziere die Datei und wiederhole den entsprechenden Task.
|
||||
|
||||
- [ ] **Step 3: Commit (optional)**
|
||||
|
||||
Falls in Task 1-4 bereits committed wurde, ist hier kein separater Commit nötig.
|
||||
|
||||
---
|
||||
|
||||
### Task 7: Push auslösen und Pipeline beobachten
|
||||
|
||||
**Files:**
|
||||
- None
|
||||
|
||||
- [ ] **Step 1: Änderungen nach Gitea pushen**
|
||||
|
||||
```bash
|
||||
git push origin main
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Pipeline-Status in Woodpecker prüfen**
|
||||
|
||||
Öffne https://ci.rebreak.org/chahine/rebreak-monorepo und warte auf den neuen Pipeline-Run.
|
||||
|
||||
- [ ] **Step 3: Erwartetes Ergebnis**
|
||||
|
||||
- `install` → grün
|
||||
- `test-backend` → grün
|
||||
- `build-backend` → grün
|
||||
- `build-admin` → grün
|
||||
- `deploy-backend` / `deploy-admin` → grün (nur bei `push` auf `main`)
|
||||
|
||||
- [ ] **Step 4: Bei rotem Test-Schritt**
|
||||
|
||||
Pipeline-Logs prüfen:
|
||||
|
||||
```bash
|
||||
ssh root@128.140.47.53
|
||||
docker logs woodpecker-agent --tail 200
|
||||
```
|
||||
|
||||
Falls es sich um ein Environment-Problem (z.B. Zeitzone, Locale) handelt, fixe es und pushe erneut.
|
||||
|
||||
---
|
||||
|
||||
## Spec Coverage Check
|
||||
|
||||
| Spec-Anforderung | Implementierender Task |
|
||||
|------------------|------------------------|
|
||||
| Backend-Tests laufen lokal erfolgreich | Task 1-6 |
|
||||
| `.woodpecker.yml` enthält `test-backend` vor Build | Task 5 |
|
||||
| Fehlschlagende Tests blockieren Deploy | Task 5 (Pipeline-Struktur) |
|
||||
| Push auf `main` führt bei grünen Tests zu Build/Deploy | Task 7 (Validierung) |
|
||||
|
||||
## Placeholder Scan
|
||||
|
||||
Keine TBDs, TODOs oder unvollständigen Code-Blöcke enthalten.
|
||||
|
||||
## Type/Signature Consistency
|
||||
|
||||
- `usePrisma`-Mock ergänzt um `domainSubmission` — konsistent mit Handler.
|
||||
- Test-Plan-Parameter `"pro"` ist gültiger Input für `getPlanLimits`.
|
||||
- Score-Werte basieren auf aktuellen `SCORE_WEIGHTS`.
|
||||
- JB-002-Mock-Antwort enthält eines der erlaubten `must_contain_any`-Patterns.
|
||||
@ -0,0 +1,73 @@
|
||||
# Design: Vitest-Integration für Backend in Woodpecker-Pipeline
|
||||
|
||||
**Datum:** 2026-06-18
|
||||
**Scope:** Backend-Tests mit Vitest in `.woodpecker.yml` integrieren
|
||||
**Decision:** Variante A — minimal, Tests als Gate vor dem Build, keine Coverage
|
||||
|
||||
---
|
||||
|
||||
## Ziel
|
||||
|
||||
`pnpm test` im Backend (`backend/`) wird in die Woodpecker-CI-Pipeline eingebunden. Fehlschlagende Tests blockieren Build und Deploy auf Staging.
|
||||
|
||||
## Ausgangslage
|
||||
|
||||
- `backend/package.json` enthält bereits `vitest` und `@vitest/coverage-v8` als Dev-Dependencies.
|
||||
- `backend/vitest.config.ts` ist konfiguriert (Node-Environment, `tests/**/*.test.ts`, Setup-File, Forks-Pool).
|
||||
- Es existieren 24 Test-Dateien unter `backend/tests/`, davon scheitern aktuell **4 Dateien mit 12 Tests**.
|
||||
- `apps/admin` hat kein Test-Setup — wird in diesem Design nicht berücksichtigt.
|
||||
- `.woodpecker.yml` enthält bisher keine Test-Phase.
|
||||
|
||||
## Fehlerhafte Tests (vor der Integration zu reparieren)
|
||||
|
||||
| Datei | Problem |
|
||||
|-------|---------|
|
||||
| `tests/social/profile-counts.test.ts` | `usePrisma().domainSubmission.count` ist `undefined` — Mock unvollständig |
|
||||
| `tests/voice/quota.test.ts` | Quota-Berechnung liefert falsche Werte (z. B. 270 statt 30, 300 statt 60) — vermutlich Datum/Reset-Logik oder falsche Mock-Daten |
|
||||
|
||||
## Architektur / Pipeline-Änderung
|
||||
|
||||
`.woodpecker.yml` bekommt einen neuen Schritt `test-backend`, der nach `install` und vor `build-backend` ausgeführt wird:
|
||||
|
||||
```yaml
|
||||
test-backend:
|
||||
image: *node_image
|
||||
commands:
|
||||
- *pnpm_setup
|
||||
- cd backend && npx nitro prepare && pnpm test
|
||||
depends_on: [install]
|
||||
```
|
||||
|
||||
`npx nitro prepare` generiert `backend/.nitro/types/tsconfig.json`, das von `backend/tsconfig.json` referenziert wird. Ohne diesen Schritt failt `vitest` mit `Cannot find module './.nitro/types/tsconfig.json'`.
|
||||
|
||||
`build-backend` und `deploy-backend` erhalten `depends_on: [test-backend, install]` bzw. bleiben von `build-backend` abhängig.
|
||||
|
||||
## Abhängigkeiten
|
||||
|
||||
- Keine externen Services nötig (Tests laufen mit gemocktem Prisma).
|
||||
- Keine neuen Secrets.
|
||||
- `node:24-slim`-Image wird wie bei allen anderen Build-Steps verwendet.
|
||||
|
||||
## Fehlerbehandlung
|
||||
|
||||
- Wenn `pnpm test` mit Exit-Code ≠ 0 endet, failt der Pipeline-Schritt.
|
||||
- Woodpecker führt daraufhin `build-backend`, `build-admin` und Deploy-Steps **nicht** aus.
|
||||
- Pull Requests werden ebenfalls getestet, aber nicht deployed (bestehende `when`-Regeln bleiben erhalten).
|
||||
|
||||
## Nicht im Scope
|
||||
|
||||
- Kein Coverage-Reporting in der Pipeline.
|
||||
- Kein Test-Setup für `apps/admin`.
|
||||
- Keine parallele Ausführung der Tests (Aufwand lohnt sich bei ~500 ms Laufzeit nicht).
|
||||
- Keine Änderung an der lokalen Entwickler-Experience außer der erwarteten grünen Test-Suite.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
1. `cd backend && pnpm test` läuft lokal erfolgreich durch (0 Fehler).
|
||||
2. `.woodpecker.yml` enthält den `test-backend`-Schritt vor den Build-Steps.
|
||||
3. Ein Push auf `main` mit fehlschlagenden Tests blockiert den Deploy.
|
||||
4. Ein Push auf `main` mit grünen Tests führt wie bisher zu Build und Deploy.
|
||||
|
||||
## Offene Punkte
|
||||
|
||||
- Keine.
|
||||
Loading…
x
Reference in New Issue
Block a user