# Gitea Cache Aktivierung - Status

**Datum:** 2025-01-XX  
**Status:** ✅ Konfiguration abgeschlossen, Deployment ausstehend

## Durchgeführte Änderungen

### 1. docker-compose.yml angepasst

**Datei:** `deployment/stacks/gitea/docker-compose.yml`

**Änderungen:**
- `GITEA__cache__ENABLED=false` → `GITEA__cache__ENABLED=true`
- `GITEA__cache__ADAPTER=memory` → `GITEA__cache__ADAPTER=redis`
- Cache-spezifische Redis-Konfiguration hinzugefügt:
  - `GITEA__cache__HOST=redis:6379`
  - `GITEA__cache__PASSWORD=${REDIS_PASSWORD:-gitea_redis_password}`
  - `GITEA__cache__DB=0`

**Vorher:**
```yaml
# Cache temporarily disabled (using memory) to debug Redis connection issue
- GITEA__cache__ENABLED=false
- GITEA__cache__ADAPTER=memory
```

**Nachher:**
```yaml
- GITEA__cache__ENABLED=true
- GITEA__cache__ADAPTER=redis
- GITEA__cache__HOST=redis:6379
- GITEA__cache__PASSWORD=${REDIS_PASSWORD:-gitea_redis_password}
- GITEA__cache__DB=0
```

### 2. Ansible Playbook erstellt

**Datei:** `deployment/ansible/playbooks/restart-gitea-with-cache.yml`

Das Playbook:
- Prüft ob Gitea Container existiert
- Erstellt Gitea Container mit neuer Cache-Konfiguration neu
- Wartet auf Gitea Health-Check
- Zeigt Erfolgsmeldung

## Nächste Schritte

### 1. Dateien auf Server synchronisieren

Die geänderte `docker-compose.yml` muss auf den Server synchronisiert werden:

```bash
cd deployment/ansible
ansible-playbook -i inventory/production.yml \
  playbooks/sync-stacks.yml \
  --vault-password-file secrets/.vault_pass
```

### 2. Gitea Container neu starten

Nach der Synchronisation Gitea mit neuer Cache-Konfiguration neu starten:

**Option A: Via Ansible Playbook**
```bash
cd deployment/ansible
ansible-playbook -i inventory/production.yml \
  playbooks/restart-gitea-with-cache.yml \
  --vault-password-file secrets/.vault_pass
```

**Option B: Manuell auf Server**
```bash
ssh deploy@94.16.110.151
cd ~/deployment/stacks/gitea
docker compose up -d --force-recreate gitea
```

### 3. Cache-Verbindung verifizieren

Nach dem Neustart prüfen:

```bash
# Gitea Logs prüfen
docker compose logs gitea | grep -i cache

# Redis-Verbindung testen
docker exec gitea-redis redis-cli -a $REDIS_PASSWORD ping

# Gitea Health-Check
curl -f https://git.michaelschiemer.de/api/healthz
```

## Erwartetes Ergebnis

Nach erfolgreichem Neustart sollte Gitea:
- ✅ Redis für Caching verwenden (statt Memory)
- ✅ Bessere Performance durch persistentes Caching
- ✅ Cache überlebt Container-Neustarts
- ✅ Keine Timeout-Probleme mehr durch Runner ohne Token

## Gitea Runner Status

**Wichtig:** Der Gitea Runner ist registriert, aber aktuell nicht gestartet. Das ist korrekt, da:
- Runner ohne Registration Token in Dauerschleife läuft
- Runner Gitea mit Requests bombardiert → Timeouts
- Runner sollte nur gestartet werden, wenn Token konfiguriert ist

**Status:**
- ✅ Runner ist registriert (`data/.runner` existiert)
- ✅ Registration Token ist in `.env` konfiguriert
- ⏸️ Runner Container sind gestoppt (korrekt, bis Deployment abgeschlossen)

**Runner starten (nach Cache-Aktivierung):**
```bash
cd deployment/gitea-runner
docker compose up -d
```

## Referenz

- [Gitea Cache Configuration](https://docs.gitea.io/en-us/config-cheat-sheet/#cache-cache)
- [Redis Configuration](https://docs.gitea.io/en-us/config-cheat-sheet/#cache-cache)
- [Gitea Runner Setup](../gitea-runner/README.md)