portfolio/DEPLOYMENT-FIXES.md

# Deployment Fixes for Gitea Actions

## Problem Summary
The Gitea Actions were failing with "Connection refused" errors when trying to connect to localhost:3000. This was caused by several issues:

1. **Incorrect Dockerfile path**: The Dockerfile was trying to copy from the wrong standalone build path
2. **Missing environment variables**: The deployment scripts weren't providing necessary environment variables
3. **Insufficient health check timeouts**: The health checks were too aggressive
4. **Poor error handling**: The workflows didn't provide enough debugging information

## Fixes Applied

### 1. Fixed Dockerfile
- **Issue**: Dockerfile was trying to copy from `/app/.next/standalone/portfolio` but the actual path was `/app/.next/standalone/app`
- **Fix**: Updated the Dockerfile to use the correct path: `/app/.next/standalone/app`
- **File**: `Dockerfile`

### 2. Enhanced Deployment Scripts
- **Issue**: Missing environment variables and poor error handling
- **Fix**: Updated `scripts/gitea-deploy.sh` with:
  - Proper environment variable handling
  - Extended health check timeout (120 seconds)
  - Better container status monitoring
  - Improved error messages and logging
- **File**: `scripts/gitea-deploy.sh`

### 3. Created Simplified Deployment Script
- **Issue**: Complex deployment with database dependencies
- **Fix**: Created `scripts/gitea-deploy-simple.sh` for testing without database dependencies
- **File**: `scripts/gitea-deploy-simple.sh`

### 4. Fixed Next.js Configuration
- **Issue**: Duplicate `serverRuntimeConfig` properties causing build failures
- **Fix**: Removed duplicate configuration and fixed the standalone build path
- **File**: `next.config.ts`

### 5. Improved Gitea Actions Workflows
- **Issue**: Poor health check logic and insufficient error handling
- **Fix**: Updated all workflow files with:
  - Better container status checking
  - Extended health check timeouts
  - Comprehensive error logging
  - Container log inspection on failures
- **Files**: 
  - `.gitea/workflows/ci-cd-fast.yml`
  - `.gitea/workflows/ci-cd-zero-downtime-fixed.yml`
  - `.gitea/workflows/ci-cd-simple.yml` (new)
  - `.gitea/workflows/ci-cd-reliable.yml` (new)

#### **5. ✅ Fixed Nginx Configuration Issue**
- **Issue**: Zero-downtime deployment failing due to missing nginx configuration file in Gitea Actions
- **Fix**: Created `docker-compose.zero-downtime-fixed.yml` with fallback nginx configuration
- **Added**: Automatic nginx config creation if file is missing
- **Files**: 
  - `docker-compose.zero-downtime-fixed.yml` (new)

#### **6. ✅ Fixed Health Check Logic**
- **Issue**: Health checks timing out even though applications were running correctly
- **Root Cause**: Workflows trying to access `localhost:3000` directly, but containers don't expose port 3000 to host
- **Fix**: Updated health check logic to:
  - Use `docker exec` for internal container health checks
  - Check nginx proxy endpoints (`localhost/api/health`) for zero-downtime deployments
  - Provide fallback health check methods
  - Better error messages and debugging information
- **Files**: 
  - `.gitea/workflows/ci-cd-zero-downtime-fixed.yml` (updated)
  - `.gitea/workflows/ci-cd-fast.yml` (updated)

## Available Workflows

### 1. CI/CD Reliable (Recommended)
- **File**: `.gitea/workflows/ci-cd-reliable.yml`
- **Description**: Simple, reliable deployment using docker-compose with database services
- **Best for**: Most reliable deployments with database support

### 2. CI/CD Simple
- **File**: `.gitea/workflows/ci-cd-simple.yml`
- **Description**: Uses the improved deployment script with comprehensive error handling
- **Best for**: Reliable deployments without database dependencies

### 3. CI/CD Fast
- **File**: `.gitea/workflows/ci-cd-fast.yml`
- **Description**: Fast deployment with rolling updates
- **Best for**: Production deployments with zero downtime

### 4. CI/CD Zero Downtime (Fixed)
- **File**: `.gitea/workflows/ci-cd-zero-downtime-fixed.yml`
- **Description**: Full zero-downtime deployment with nginx load balancer (fixed nginx config issue)
- **Best for**: Production deployments requiring high availability

## Testing the Fixes

### Local Testing
```bash
# Test the simplified deployment script
./scripts/gitea-deploy-simple.sh

# Test the full deployment script
./scripts/gitea-deploy.sh
```

### Verification
```bash
# Check if the application is running
curl -f http://localhost:3000/api/health

# Check the main page
curl -f http://localhost:3000/
```

## Environment Variables Required

### Variables (in Gitea repository settings)
- `NODE_ENV`: production
- `LOG_LEVEL`: info
- `NEXT_PUBLIC_BASE_URL`: https://dk0.dev
- `NEXT_PUBLIC_UMAMI_URL`: https://analytics.dk0.dev
- `NEXT_PUBLIC_UMAMI_WEBSITE_ID`: b3665829-927a-4ada-b9bb-fcf24171061e
- `MY_EMAIL`: contact@dk0.dev
- `MY_INFO_EMAIL`: info@dk0.dev

### Secrets (in Gitea repository settings)
- `MY_PASSWORD`: Your email password
- `MY_INFO_PASSWORD`: Your info email password
- `ADMIN_BASIC_AUTH`: admin:your_secure_password_here

## Troubleshooting

### If deployment still fails:
1. Check the Gitea Actions logs for specific error messages
2. Verify all environment variables and secrets are set correctly
3. Check if the Docker image builds successfully locally
4. Ensure the health check endpoint is accessible

### Common Issues:
- **"Connection refused"**: Container failed to start or crashed
- **"Health check timeout"**: Application is taking too long to start
- **"Build failed"**: Docker build issues, check Dockerfile and dependencies

## Next Steps
1. Push these changes to your Gitea repository
2. The Actions should now work without the "Connection refused" errors
3. Monitor the deployment logs for any remaining issues
4. Consider using the "CI/CD Simple" workflow for the most reliable deployments