diff --git a/DEPLOYMENT_SETUP.md b/DEPLOYMENT_SETUP.md deleted file mode 100644 index 20636a2..0000000 --- a/DEPLOYMENT_SETUP.md +++ /dev/null @@ -1,200 +0,0 @@ -# 🚀 Deployment Setup Guide - -## Overview - -This project uses a **dual-branch deployment strategy** with zero-downtime deployments: - -- **Production Branch** (`production`) → Serves `https://dk0.dev` on port 3000 -- **Dev Branch** (`dev`) → Serves `https://dev.dk0.dev` on port 3002 - -Both environments are completely isolated with separate: -- Docker containers -- Databases (PostgreSQL) -- Redis instances -- Networks -- Volumes - -## Branch Strategy - -### Production Branch -- **Branch**: `production` -- **Domain**: `https://dk0.dev` -- **Port**: `3000` -- **Container**: `portfolio-app` -- **Database**: `portfolio_db` (port 5432) -- **Redis**: `portfolio-redis` (port 6379) -- **Image Tag**: `portfolio-app:production` / `portfolio-app:latest` - -### Dev Branch -- **Branch**: `dev` -- **Domain**: `https://dev.dk0.dev` -- **Port**: `3002` -- **Container**: `portfolio-app-staging` -- **Database**: `portfolio_staging_db` (port 5434) -- **Redis**: `portfolio-redis-staging` (port 6381) -- **Image Tag**: `portfolio-app:staging` - -## Automatic Deployment - -### How It Works - -1. **Push to `production` branch**: - - Triggers `.gitea/workflows/production-deploy.yml` - - Runs tests, builds, and deploys to production - - Zero-downtime deployment (starts new container, waits for health, removes old) - -2. **Push to `dev` branch**: - - Triggers `.gitea/workflows/dev-deploy.yml` - - Runs tests, builds, and deploys to dev/staging - - Zero-downtime deployment - -### Zero-Downtime Process - -1. Build new Docker image -2. Start new container with updated image -3. Wait for new container to be healthy (health checks) -4. Verify HTTP endpoints respond correctly -5. Remove old container (if different) -6. Cleanup old images - -## Manual Deployment - -### Production -```bash -# Build and deploy production -docker build -t portfolio-app:latest . -docker compose -f docker-compose.production.yml up -d --build -``` - -### Dev/Staging -```bash -# Build and deploy dev -docker build -t portfolio-app:staging . -docker compose -f docker-compose.staging.yml up -d --build -``` - -## Environment Variables - -### Required Gitea Variables -- `NEXT_PUBLIC_BASE_URL` - Base URL for the application -- `MY_EMAIL` - Email address for contact -- `MY_INFO_EMAIL` - Info email address -- `LOG_LEVEL` - Logging level (info/debug) - -### Required Gitea Secrets -- `MY_PASSWORD` - Email password -- `MY_INFO_PASSWORD` - Info email password -- `ADMIN_BASIC_AUTH` - Admin basic auth credentials -- `N8N_SECRET_TOKEN` - Optional: n8n webhook secret - -### Optional Variables -- `N8N_WEBHOOK_URL` - n8n webhook URL for automation - -## Health Checks - -Both environments have health check endpoints: -- Production: `http://localhost:3000/api/health` -- Dev: `http://localhost:3002/api/health` - -## Monitoring - -### Check Container Status -```bash -# Production -docker compose -f docker-compose.production.yml ps - -# Dev -docker compose -f docker-compose.staging.yml ps -``` - -### View Logs -```bash -# Production -docker logs portfolio-app --tail=100 -f - -# Dev -docker logs portfolio-app-staging --tail=100 -f -``` - -### Health Check -```bash -# Production -curl http://localhost:3000/api/health - -# Dev -curl http://localhost:3002/api/health -``` - -## Troubleshooting - -### Container Won't Start -1. Check logs: `docker logs ` -2. Verify environment variables are set -3. Check database/redis connectivity -4. Verify ports aren't already in use - -### Deployment Fails -1. Check Gitea Actions logs -2. Verify all required secrets/variables are set -3. Check if old containers are blocking ports -4. Verify Docker image builds successfully - -### Zero-Downtime Issues -- Old container might still be running - check with `docker ps` -- Health checks might be failing - check container logs -- Port conflicts - verify ports 3000 and 3002 are available - -## Rollback - -If a deployment fails or causes issues: - -```bash -# Production rollback -docker compose -f docker-compose.production.yml down -docker tag portfolio-app:previous portfolio-app:latest -docker compose -f docker-compose.production.yml up -d - -# Dev rollback -docker compose -f docker-compose.staging.yml down -docker tag portfolio-app:staging-previous portfolio-app:staging -docker compose -f docker-compose.staging.yml up -d -``` - -## Best Practices - -1. **Always test on dev branch first** before pushing to production -2. **Monitor health checks** after deployment -3. **Keep old images** for quick rollback (last 3 versions) -4. **Use feature flags** for new features -5. **Document breaking changes** before deploying -6. **Run tests locally** before pushing - -## Network Configuration - -- **Production Network**: `portfolio_net` + `proxy` (external) -- **Dev Network**: `portfolio_staging_net` -- **Isolation**: Complete separation ensures no interference - -## Database Management - -### Production Database -- **Container**: `portfolio-postgres` -- **Port**: `5432` (internal only) -- **Database**: `portfolio_db` -- **User**: `portfolio_user` - -### Dev Database -- **Container**: `portfolio-postgres-staging` -- **Port**: `5434` (external), `5432` (internal) -- **Database**: `portfolio_staging_db` -- **User**: `portfolio_user` - -## Redis Configuration - -### Production Redis -- **Container**: `portfolio-redis` -- **Port**: `6379` (internal only) - -### Dev Redis -- **Container**: `portfolio-redis-staging` -- **Port**: `6381` (external), `6379` (internal) diff --git a/DEV-SETUP.md b/DEV-SETUP.md deleted file mode 100644 index 8cb5710..0000000 --- a/DEV-SETUP.md +++ /dev/null @@ -1,239 +0,0 @@ -# 🚀 Development Environment Setup - -This document explains how to set up and use the development environment for the portfolio project. - -## ✨ Features - -- **Automatic Database Setup**: PostgreSQL and Redis start automatically -- **Hot Reload**: Next.js development server with hot reload -- **Database Integration**: Real database integration for email management -- **Modern Admin Dashboard**: Completely redesigned admin interface -- **Minimal Setup**: Only essential services for fast development - -## 🛠️ Quick Start - -### Prerequisites - -- Node.js 18+ -- Docker & Docker Compose -- npm or yarn - -### 1. Install Dependencies - -```bash -npm install -``` - -### 2. Start Development Environment - -#### Option A: Full Development Environment (with Docker) -```bash -npm run dev -``` - -This single command will: -- Start PostgreSQL database -- Start Redis cache -- Start Next.js development server -- Set up all environment variables - -#### Option B: Simple Development Mode (without Docker) -```bash -npm run dev:simple -``` - -This starts only the Next.js development server without Docker services. Use this if you don't have Docker installed or want a faster startup. - -### 3. Access Services - -- **Portfolio**: http://localhost:3000 -- **Admin Dashboard**: http://localhost:3000/manage -- **PostgreSQL**: localhost:5432 -- **Redis**: localhost:6379 - -## 📧 Email Testing - -The development environment supports email functionality: - -1. Send emails through the contact form or admin panel -2. Emails are sent directly (configure SMTP in production) -3. Check console logs for email debugging - -## 🗄️ Database - -### Development Database - -- **Host**: localhost:5432 -- **Database**: portfolio_dev -- **User**: portfolio_user -- **Password**: portfolio_dev_pass - -### Database Commands - -```bash -# Generate Prisma client -npm run db:generate - -# Push schema changes -npm run db:push - -# Seed database with sample data -npm run db:seed - -# Open Prisma Studio -npm run db:studio - -# Reset database -npm run db:reset -``` - -## 🎨 Admin Dashboard - -The new admin dashboard includes: - -- **Overview**: Statistics and recent activity -- **Projects**: Manage portfolio projects -- **Emails**: Handle contact form submissions with beautiful templates -- **Analytics**: View performance metrics -- **Settings**: Import/export functionality - -### Email Templates - -Three beautiful email templates are available: - -1. **Welcome Template** (Green): Friendly greeting with portfolio links -2. **Project Template** (Purple): Professional project discussion response -3. **Quick Template** (Orange): Fast acknowledgment response - -## 🔧 Environment Variables - -Create a `.env.local` file: - -```env -# Development Database -DATABASE_URL="postgresql://portfolio_user:portfolio_dev_pass@localhost:5432/portfolio_dev?schema=public" - -# Redis -REDIS_URL="redis://localhost:6379" - -# Email (for production) -MY_EMAIL=contact@dk0.dev -MY_PASSWORD=your-email-password - -# Application -NEXT_PUBLIC_BASE_URL=http://localhost:3000 -NODE_ENV=development -``` - -## 🛑 Stopping the Environment - -Use Ctrl+C to stop all services, or: - -```bash -# Stop Docker services only -npm run docker:dev:down -``` - -## 🐳 Docker Commands - -```bash -# Start only database services -npm run docker:dev - -# Stop database services -npm run docker:dev:down - -# View logs -docker compose -f docker-compose.dev.minimal.yml logs -f -``` - -## 📁 Project Structure - -``` -├── docker-compose.dev.minimal.yml # Minimal development services -├── scripts/ -│ ├── dev-minimal.js # Main development script -│ ├── dev-simple.js # Simple development script -│ ├── setup-database.js # Database setup script -│ └── init-db.sql # Database initialization -├── app/ -│ ├── admin/ # Admin dashboard -│ ├── api/ -│ │ ├── contacts/ # Contact management API -│ │ └── email/ # Email sending API -│ └── components/ -│ ├── ModernAdminDashboard.tsx -│ ├── EmailManager.tsx -│ └── EmailResponder.tsx -└── prisma/ - └── schema.prisma # Database schema -``` - -## 🚨 Troubleshooting - -### Docker Compose Not Found - -If you get the error `spawn docker compose ENOENT`: - -```bash -# Try the simple dev mode instead -npm run dev:simple - -# Or install Docker Desktop -# Download from: https://www.docker.com/products/docker-desktop -``` - -### Port Conflicts - -If ports are already in use: - -```bash -# Check what's using the ports -lsof -i :3000 -lsof -i :5432 -lsof -i :6379 - -# Kill processes if needed -kill -9 -``` - -### Database Connection Issues - -```bash -# Restart database services -npm run docker:dev:down -npm run docker:dev - -# Check database status -docker compose -f docker-compose.dev.minimal.yml ps -``` - -### Email Not Working - -1. Verify environment variables -2. Check browser console for errors -3. Ensure SMTP is configured for production - -## 🎯 Production Deployment - -For production deployment, use: - -```bash -npm run build -npm run start -``` - -The production environment uses the production Docker Compose configuration. - -## 📝 Notes - -- The development environment automatically creates sample data -- Database changes are persisted in Docker volumes -- Hot reload works for all components and API routes -- Minimal setup for fast development startup - -## 🔗 Links - -- **Portfolio**: https://dk0.dev -- **Admin**: https://dk0.dev/manage -- **GitHub**: https://github.com/denniskonkol/portfolio diff --git a/GITEA_VARIABLES_SETUP.md b/GITEA_VARIABLES_SETUP.md deleted file mode 100644 index 1c12127..0000000 --- a/GITEA_VARIABLES_SETUP.md +++ /dev/null @@ -1,153 +0,0 @@ -# 🔧 Gitea Variables & Secrets Setup Guide - -## Übersicht - -In Gitea kannst du **Variables** (öffentlich) und **Secrets** (verschlüsselt) für dein Repository setzen. Diese werden in den CI/CD Workflows verwendet. - -## 📍 Wo findest du die Einstellungen? - -1. Gehe zu deinem Repository auf Gitea -2. Klicke auf **Settings** (Einstellungen) -3. Klicke auf **Variables** oder **Secrets** im linken Menü - -## 🔑 Variablen für Production Branch (`production` → `dk0.dev`) - -Für den `production` Branch brauchst du: - -### Variables (öffentlich sichtbar): -- `NEXT_PUBLIC_BASE_URL_PRODUCTION` = `https://dk0.dev` -- `MY_EMAIL` = `contact@dk0.dev` (oder deine Email) -- `MY_INFO_EMAIL` = `info@dk0.dev` (oder deine Info-Email) -- `LOG_LEVEL` = `info` -- `N8N_WEBHOOK_URL` = `https://n8n.dk0.dev` (optional) - -### Secrets (verschlüsselt): -- `MY_PASSWORD` = Dein Email-Passwort -- `MY_INFO_PASSWORD` = Dein Info-Email-Passwort -- `ADMIN_BASIC_AUTH` = `admin:dein_sicheres_passwort` -- `ADMIN_SESSION_SECRET` = zufälliger Secret (mind. 32 Zeichen) -- `N8N_SECRET_TOKEN` = Dein n8n Secret Token (optional) - -## 🧪 Variablen für Dev Branch - -Für den `testing` Branch brauchst du die **gleichen** Variablen, aber mit anderen Werten: - -### Variables: -- `NEXT_PUBLIC_BASE_URL_TESTING` = `https://testing.dk0.dev` ⚠️ **WICHTIG: Andere URL!** -- `MY_EMAIL` = `contact@dk0.dev` (kann gleich sein) -- `MY_INFO_EMAIL` = `info@dk0.dev` (kann gleich sein) -- `LOG_LEVEL` = `debug` (für Dev mehr Logging) -- `N8N_WEBHOOK_URL` = `https://n8n.dk0.dev` (optional) - -### Secrets: -- `MY_PASSWORD` = Dein Email-Passwort (kann gleich sein) -- `MY_INFO_PASSWORD` = Dein Info-Email-Passwort (kann gleich sein) -- `ADMIN_BASIC_AUTH` = `admin:testing_password` (kann anders sein) -- `ADMIN_SESSION_SECRET` = zufälliger Secret (mind. 32 Zeichen; kann gleich sein) -- `N8N_SECRET_TOKEN` = Dein n8n Secret Token (optional) - -## ✅ Lösung: Automatische Branch-Erkennung - -**Gitea unterstützt keine branch-spezifischen Variablen, aber die Workflows erkennen automatisch den Branch!** - -### Wie es funktioniert: - -Die Workflows triggern auf unterschiedlichen Branches und verwenden automatisch die richtigen Defaults: - -**Production Workflow** (`.gitea/workflows/production-deploy.yml`): -- Triggert nur auf `production` Branch -- Verwendet: `NEXT_PUBLIC_BASE_URL_PRODUCTION` (wenn gesetzt) oder Default: `https://dk0.dev` - -**Testing Workflow** (`.gitea/workflows/dev-deploy.yml`): -- Triggert nur auf `testing` Branch -- Verwendet: `NEXT_PUBLIC_BASE_URL_TESTING` (wenn gesetzt) oder Default: `https://testing.dk0.dev` - -**Das bedeutet:** -- Du setzt **zwei** Variablen in Gitea (empfohlen, weil Gitea nicht branch-spezifisch scoped): - - `NEXT_PUBLIC_BASE_URL_PRODUCTION` - - `NEXT_PUBLIC_BASE_URL_TESTING` - -### ⚠️ WICHTIG: -Gitea kann Variablen/Secrets nicht pro Branch trennen. Darum nutzen wir **separate Variablennamen** für Production und Testing. - -## ✅ Empfohlene Konfiguration - -### ⭐ Einfachste Lösung: nur URLs setzen (optional) - -Die Workflows haben bereits die richtigen Defaults: -- **Production Branch** → automatisch `https://dk0.dev` -- **Testing Branch** → automatisch `https://testing.dk0.dev` - -Du musst **NICHTS** in Gitea setzen, es funktioniert automatisch! - -### Wenn du Variablen setzen willst: - -**Nur diese Variablen setzen (für beide Branches):** -- `MY_EMAIL` = `contact@dk0.dev` -- `MY_INFO_EMAIL` = `info@dk0.dev` -- `LOG_LEVEL` = `info` (wird für Production verwendet, Dev überschreibt mit `debug`) - -**Secrets (für beide Branches):** -- `MY_PASSWORD` = Dein Email-Passwort -- `MY_INFO_PASSWORD` = Dein Info-Email-Passwort -- `ADMIN_BASIC_AUTH` = `admin:dein_passwort` -- `ADMIN_SESSION_SECRET` = zufälliger Secret (mind. 32 Zeichen) -- `N8N_SECRET_TOKEN` = Dein n8n Token (optional) - -**Optional setzen:** -- `NEXT_PUBLIC_BASE_URL_PRODUCTION` = `https://dk0.dev` -- `NEXT_PUBLIC_BASE_URL_TESTING` = `https://testing.dk0.dev` - -## 📝 Schritt-für-Schritt Anleitung - -### 1. Gehe zu Repository Settings -``` -https://git.dk0.dev/denshooter/portfolio/settings -``` - -### 2. Klicke auf "Variables" oder "Secrets" - -### 3. Für Variables (öffentlich): -- Klicke auf **"New Variable"** -- **Name:** `NEXT_PUBLIC_BASE_URL_PRODUCTION` -- **Value:** `https://dk0.dev` -- **Protect:** ✅ (optional, schützt vor Änderungen) -- Klicke **"Add Variable"** - -- Klicke auf **"New Variable"** -- **Name:** `NEXT_PUBLIC_BASE_URL_TESTING` -- **Value:** `https://testing.dk0.dev` -- **Protect:** ✅ (optional) -- Klicke **"Add Variable"** - -### 4. Für Secrets (verschlüsselt): -- Klicke auf **"New Secret"** -- **Name:** `MY_PASSWORD` -- **Value:** Dein Passwort -- Klicke **"Add Secret"** - -## 🔄 Aktuelle Workflow-Logik - -Die Workflows verwenden diese einfache Logik: - -```yaml -# Production Workflow (triggert nur auf production branch) -NEXT_PUBLIC_BASE_URL: ${{ vars.NEXT_PUBLIC_BASE_URL_PRODUCTION || 'https://dk0.dev' }} - -# Testing Workflow (triggert nur auf testing branch) -NEXT_PUBLIC_BASE_URL: ${{ vars.NEXT_PUBLIC_BASE_URL_TESTING || 'https://testing.dk0.dev' }} -``` - -**Das bedeutet:** -- Jeder Workflow hat seinen **eigenen Default** -- Wenn die jeweilige Variable (`NEXT_PUBLIC_BASE_URL_PRODUCTION` / `NEXT_PUBLIC_BASE_URL_TESTING`) in Gitea gesetzt ist, wird diese verwendet -- Wenn **nicht** gesetzt, verwendet jeder Branch seinen eigenen Default - -**⭐ Beste Lösung:** -- Setze `NEXT_PUBLIC_BASE_URL_PRODUCTION` und `NEXT_PUBLIC_BASE_URL_TESTING` (oder lass beide weg und nutze Defaults). - -## 🎯 Best Practice - -1. **Production (`production`)**: `docker-compose.production.yml` → Port 3000 → NPM Host `dk0.dev` -2. **Testing (`testing`)**: `docker-compose.testing.yml` → Port 3002 → NPM Host `testing.dk0.dev` -3. **Secrets**: immer als Gitea Secrets, nie im Code diff --git a/NGINX_PROXY_MANAGER_SETUP.md b/NGINX_PROXY_MANAGER_SETUP.md deleted file mode 100644 index 1424a1f..0000000 --- a/NGINX_PROXY_MANAGER_SETUP.md +++ /dev/null @@ -1,198 +0,0 @@ -# 🔧 Nginx Proxy Manager Setup Guide - -## Übersicht - -Dieses Projekt nutzt **Nginx Proxy Manager** als Reverse Proxy. Die Container sind im `proxy` Netzwerk, damit Nginx Proxy Manager auf sie zugreifen kann. - -## 🐳 Docker Netzwerk-Konfiguration - -Die Container sind bereits im `proxy` Netzwerk konfiguriert: - -**Production:** -```yaml -networks: - - portfolio_net - - proxy # ✅ Bereits konfiguriert -``` - -**Staging:** -```yaml -networks: - - portfolio_staging_net - - proxy # ✅ Bereits konfiguriert -``` - -## 📋 Nginx Proxy Manager Konfiguration - -### Production (dk0.dev) - -1. **Gehe zu Nginx Proxy Manager** → Hosts → Proxy Hosts → Add Proxy Host - -2. **Details Tab:** - - **Domain Names:** `dk0.dev`, `www.dk0.dev` - - **Scheme:** `http` - - **Forward Hostname/IP:** `portfolio-app` (Container-Name) - - **Forward Port:** `3000` - - **Cache Assets:** ✅ (optional) - - **Block Common Exploits:** ✅ - - **Websockets Support:** ✅ (für Chat/Activity) - -3. **SSL Tab:** - - **SSL Certificate:** Request a new SSL Certificate - - **Force SSL:** ✅ - - **HTTP/2 Support:** ✅ - - **HSTS Enabled:** ✅ - -4. **Advanced Tab:** - ``` - # Custom Nginx Configuration - # Fix for 421 Misdirected Request - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - proxy_set_header X-Forwarded-Proto $scheme; - proxy_set_header X-Forwarded-Host $host; - proxy_set_header X-Forwarded-Port $server_port; - - # Fix HTTP/2 connection reuse issues - proxy_http_version 1.1; - proxy_set_header Connection ""; - - # Timeouts - proxy_connect_timeout 60s; - proxy_send_timeout 60s; - proxy_read_timeout 60s; - ``` - -### Staging (dev.dk0.dev) - -1. **Gehe zu Nginx Proxy Manager** → Hosts → Proxy Hosts → Add Proxy Host - -2. **Details Tab:** - - **Domain Names:** `dev.dk0.dev` - - **Scheme:** `http` - - **Forward Hostname/IP:** `portfolio-app-staging` (Container-Name) - - **Forward Port:** `3000` (interner Port im Container) - - **Cache Assets:** ❌ (für Dev besser deaktiviert) - - **Block Common Exploits:** ✅ - - **Websockets Support:** ✅ - -3. **SSL Tab:** - - **SSL Certificate:** Request a new SSL Certificate - - **Force SSL:** ✅ - - **HTTP/2 Support:** ✅ - - **HSTS Enabled:** ✅ - -4. **Advanced Tab:** - ``` - # Custom Nginx Configuration - # Fix for 421 Misdirected Request - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - proxy_set_header X-Forwarded-Proto $scheme; - proxy_set_header X-Forwarded-Host $host; - proxy_set_header X-Forwarded-Port $server_port; - - # Fix HTTP/2 connection reuse issues - proxy_http_version 1.1; - proxy_set_header Connection ""; - - # Timeouts - proxy_connect_timeout 60s; - proxy_send_timeout 60s; - proxy_read_timeout 60s; - ``` - -## 🔍 421 Misdirected Request - Lösung - -Der **421 Misdirected Request** Fehler tritt auf, wenn: - -1. **HTTP/2 Connection Reuse:** Nginx Proxy Manager versucht, eine HTTP/2-Verbindung wiederzuverwenden, aber der Host-Header stimmt nicht überein -2. **Host-Header nicht richtig weitergegeben:** Der Container erhält den falschen Host-Header - -### Lösung 1: Advanced Tab Konfiguration (Wichtig!) - -Füge diese Zeilen im **Advanced Tab** von Nginx Proxy Manager hinzu: - -```nginx -proxy_http_version 1.1; -proxy_set_header Connection ""; -proxy_set_header Host $host; -proxy_set_header X-Forwarded-Host $host; -``` - -### Lösung 2: Container-Namen verwenden - -Stelle sicher, dass du den **Container-Namen** (nicht IP) verwendest: -- Production: `portfolio-app` -- Staging: `portfolio-app-staging` - -### Lösung 3: Netzwerk prüfen - -Stelle sicher, dass beide Container im `proxy` Netzwerk sind: - -```bash -# Prüfen -docker network inspect proxy - -# Sollte enthalten: -# - portfolio-app -# - portfolio-app-staging -``` - -## ✅ Checkliste - -- [ ] Container sind im `proxy` Netzwerk -- [ ] Nginx Proxy Manager nutzt Container-Namen (nicht IP) -- [ ] Advanced Tab Konfiguration ist gesetzt -- [ ] `proxy_http_version 1.1` ist gesetzt -- [ ] `proxy_set_header Host $host` ist gesetzt -- [ ] SSL-Zertifikat ist konfiguriert -- [ ] Websockets Support ist aktiviert - -## 🐛 Troubleshooting - -### 421 Fehler weiterhin vorhanden? - -1. **Prüfe Container-Namen:** - ```bash - docker ps --format "table {{.Names}}\t{{.Status}}" - ``` - -2. **Prüfe Netzwerk:** - ```bash - docker network inspect proxy | grep -A 5 portfolio - ``` - -3. **Prüfe Nginx Proxy Manager Logs:** - - Gehe zu Nginx Proxy Manager → System Logs - - Suche nach "421" oder "misdirected" - -4. **Teste direkt:** - ```bash - # Vom Host aus - curl -H "Host: dk0.dev" http://portfolio-app:3000 - - # Sollte funktionieren - ``` - -5. **Deaktiviere HTTP/2 temporär:** - - In Nginx Proxy Manager → SSL Tab - - **HTTP/2 Support:** ❌ - - Teste ob es funktioniert - -## 📝 Wichtige Hinweise - -- **Container-Namen sind wichtig:** Nutze `portfolio-app` nicht `localhost` oder IP -- **Port:** Immer Port `3000` (interner Container-Port), nicht `3000:3000` -- **Netzwerk:** Beide Container müssen im `proxy` Netzwerk sein -- **HTTP/2:** Kann Probleme verursachen, wenn Advanced Config fehlt - -## 🔄 Nach Deployment - -Nach jedem Deployment: -1. Prüfe ob Container läuft: `docker ps | grep portfolio` -2. Prüfe ob Container im proxy-Netzwerk ist -3. Teste die URL im Browser -4. Prüfe Nginx Proxy Manager Logs bei Problemen diff --git a/TESTING_GUIDE.md b/TESTING_GUIDE.md deleted file mode 100644 index 1df1443..0000000 --- a/TESTING_GUIDE.md +++ /dev/null @@ -1,284 +0,0 @@ -# 🧪 Automated Testing Guide - -This guide explains how to run automated tests for critical paths, hydration, emails, and more. - -## 📋 Test Types - -### 1. Unit Tests (Jest) -Tests individual components and functions in isolation. - -```bash -npm run test # Run all unit tests -npm run test:watch # Watch mode -npm run test:coverage # With coverage report -``` - -### 2. E2E Tests (Playwright) -Tests complete user flows in a real browser. - -```bash -npm run test:e2e # Run all E2E tests -npm run test:e2e:ui # Run with UI mode (visual) -npm run test:e2e:headed # Run with visible browser -npm run test:e2e:debug # Debug mode -``` - -### 3. Critical Path Tests -Tests the most important user flows. - -```bash -npm run test:critical # Run critical path tests only -``` - -### 4. Hydration Tests -Ensures React hydration works without errors. - -```bash -npm run test:hydration # Run hydration tests only -``` - -### 5. Email Tests -Tests email API endpoints. - -```bash -npm run test:email # Run email tests only -``` - -### 6. Performance Tests -Checks page load times and performance. - -```bash -npm run test:performance # Run performance tests -``` - -### 7. Accessibility Tests -Basic accessibility checks. - -```bash -npm run test:accessibility # Run accessibility tests -``` - -## 🚀 Running All Tests - -### Quick Test (Recommended) -```bash -npm run test:all -``` - -This runs: -- ✅ TypeScript check -- ✅ ESLint -- ✅ Build -- ✅ Unit tests -- ✅ Critical paths -- ✅ Hydration tests -- ✅ Email tests -- ✅ Performance tests -- ✅ Accessibility tests - -### Individual Test Suites -```bash -# Unit tests only -npm run test - -# E2E tests only -npm run test:e2e - -# Both -npm run test && npm run test:e2e -``` - -## 📝 What Gets Tested - -### Critical Paths -- ✅ Home page loads correctly -- ✅ Projects page displays projects -- ✅ Individual project pages work -- ✅ Admin dashboard is accessible -- ✅ API health endpoint -- ✅ API projects endpoint - -### Hydration -- ✅ No hydration errors in console -- ✅ No duplicate React key warnings -- ✅ Client-side navigation works -- ✅ Server and client HTML match -- ✅ Interactive elements work after hydration - -### Email -- ✅ Email API accepts requests -- ✅ Required field validation -- ✅ Email format validation -- ✅ Rate limiting (if implemented) -- ✅ Email respond endpoint - -### Performance -- ✅ Page load times (< 5s) -- ✅ No large layout shifts -- ✅ Images are optimized -- ✅ API response times (< 1s) - -### Accessibility -- ✅ Proper heading structure -- ✅ Images have alt text -- ✅ Links have descriptive text -- ✅ Forms have labels - -## 🎯 Pre-Push Testing - -Before pushing to main, run: - -```bash -# Full test suite -npm run test:all - -# Or manually: -npm run build -npm run lint -npx tsc --noEmit -npm run test -npm run test:critical -npm run test:hydration -``` - -## 🔧 Configuration - -### Playwright Config -Located in `playwright.config.ts` - -- **Base URL**: `http://localhost:3000` (or set `PLAYWRIGHT_TEST_BASE_URL`) -- **Browsers**: Chromium, Firefox, WebKit, Mobile Chrome, Mobile Safari -- **Retries**: 2 retries in CI, 0 locally -- **Screenshots**: On failure -- **Videos**: On failure - -### Jest Config -Located in `jest.config.ts` - -- **Environment**: jsdom -- **Coverage**: v8 provider -- **Setup**: `jest.setup.ts` - -## 🐛 Debugging Tests - -### Playwright Debug Mode -```bash -npm run test:e2e:debug -``` - -This opens Playwright Inspector where you can: -- Step through tests -- Inspect elements -- View console logs -- See network requests - -### UI Mode (Visual) -```bash -npm run test:e2e:ui -``` - -Shows a visual interface to: -- See all tests -- Run specific tests -- Watch tests execute -- View results - -### Headed Mode -```bash -npm run test:e2e:headed -``` - -Runs tests with visible browser (useful for debugging). - -## 📊 Test Reports - -### Playwright HTML Report -After running E2E tests: -```bash -npx playwright show-report -``` - -Shows: -- Test results -- Screenshots on failure -- Videos on failure -- Timeline of test execution - -### Jest Coverage Report -```bash -npm run test:coverage -``` - -Generates coverage report in `coverage/` directory. - -## 🚨 Common Issues - -### Tests Fail Locally But Pass in CI -- Check environment variables -- Ensure database is set up -- Check for port conflicts - -### Hydration Errors -- Check for server/client mismatches -- Ensure no conditional rendering based on `window` -- Check for date/time differences - -### Email Tests Fail -- Email service might not be configured -- Check environment variables -- Tests are designed to handle missing email service - -### Performance Tests Fail -- Network might be slow -- Adjust thresholds in test file -- Check for heavy resources loading - -## 📝 Writing New Tests - -### E2E Test Example -```typescript -import { test, expect } from '@playwright/test'; - -test('My new feature works', async ({ page }) => { - await page.goto('/my-page'); - await expect(page.locator('h1')).toContainText('Expected Text'); -}); -``` - -### Unit Test Example -```typescript -import { render, screen } from '@testing-library/react'; -import MyComponent from './MyComponent'; - -test('renders correctly', () => { - render(); - expect(screen.getByText('Hello')).toBeInTheDocument(); -}); -``` - -## 🎯 CI/CD Integration - -### GitHub Actions Example -```yaml -- name: Run tests - run: | - npm install - npm run test:all -``` - -### Pre-Push Hook -Add to `.git/hooks/pre-push`: -```bash -#!/bin/bash -npm run test:all -``` - -## 📚 Resources - -- [Playwright Docs](https://playwright.dev) -- [Jest Docs](https://jestjs.io) -- [Testing Library](https://testing-library.com) - ---- - -**Remember**: Tests should be fast, reliable, and easy to understand! 🚀 diff --git a/docs/TESTING_AND_DEPLOYMENT.md b/docs/TESTING_AND_DEPLOYMENT.md deleted file mode 100644 index 93fdcdc..0000000 --- a/docs/TESTING_AND_DEPLOYMENT.md +++ /dev/null @@ -1,69 +0,0 @@ -# Testing & Deployment (Gitea → Docker → Nginx Proxy Manager) - -## Ziel - -- **Production**: Branch `production` → Container `portfolio-app` → `dk0.dev` (Port `3000`) -- **Testing**: Branch `testing` → Container `portfolio-app-testing` → `testing.dk0.dev` (Port `3002`) - -Beide Stacks laufen parallel und sind komplett getrennt (eigene Postgres/Redis/Volumes). - -## DNS / Nginx Proxy Manager - -### DNS -- Setze `A` (oder `CNAME`) Records: - - `dk0.dev` → dein Server - - `testing.dk0.dev` → dein Server - -### Nginx Proxy Manager -Lege zwei Proxy Hosts an: - -- **`dk0.dev`** - - Forward Hostname/IP: `127.0.0.1` (oder Server-IP) - - Forward Port: `3000` - -- **`testing.dk0.dev`** - - Forward Hostname/IP: `127.0.0.1` (oder Server-IP) - - Forward Port: `3002` - -Dann SSL Zertifikate (Let’s Encrypt) aktivieren. - -## Gitea Workflows - -- `production` push → `.gitea/workflows/production-deploy.yml` -- `testing` push → `.gitea/workflows/dev-deploy.yml` (umbenannt im Namen, Inhalt ist Testing) - -### Benötigte Variables (Gitea) -- `NEXT_PUBLIC_BASE_URL_PRODUCTION` = `https://dk0.dev` -- `NEXT_PUBLIC_BASE_URL_TESTING` = `https://testing.dk0.dev` -- optional: `MY_EMAIL`, `MY_INFO_EMAIL`, `LOG_LEVEL`, `N8N_WEBHOOK_URL`, `N8N_API_KEY` - -### Benötigte Secrets (Gitea) -- `MY_PASSWORD` -- `MY_INFO_PASSWORD` -- `ADMIN_BASIC_AUTH` (z.B. `admin:`) -- `ADMIN_SESSION_SECRET` (mind. 32 Zeichen, zufällig; für Session-Login im Admin) -- optional: `N8N_SECRET_TOKEN` - -## Docker Compose Files - -- Production: `docker-compose.production.yml` (Port 3000) -- Testing: `docker-compose.testing.yml` (Port 3002) - -Wenn du “dev” nicht mehr brauchst, kannst du den Branch einfach nicht mehr benutzen. - -## Prisma Migrations (Auto-Deploy) - -Der App-Container führt beim Start automatisch aus: -- `prisma migrate deploy` - -### Wichtig: bestehende Datenbank (Baseline) -Wenn deine DB bereits existiert (vor Einführung von Prisma Migrations), dann würde die initiale Migration sonst mit “table already exists” scheitern. - -**Einmalig beim ersten Deploy**: -- Setze `PRISMA_AUTO_BASELINE=true` (z.B. als Compose env oder Gitea Variable/Secret) -- Deploy ausführen -- Danach wieder auf `false` setzen - -Alternative (manuell/sauber): -- Baseline per `prisma migrate resolve --applied ` ausführen (z.B. lokal gegen die Prod-DB) - diff --git a/playwright-report/index.html b/playwright-report/index.html deleted file mode 100644 index f3e3b9e..0000000 --- a/playwright-report/index.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - - - Playwright Test Report - - - - -
- - - \ No newline at end of file