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)

Available Workflows

1. CI/CD Simple (Recommended)

• File: .gitea/workflows/ci-cd-simple.yml
• Description: Uses the improved deployment script with comprehensive error handling
• Best for: Reliable deployments with good debugging

2. CI/CD Fast

• File: .gitea/workflows/ci-cd-fast.yml
• Description: Fast deployment with rolling updates
• Best for: Production deployments with zero downtime

3. CI/CD Zero Downtime

• File: .gitea/workflows/ci-cd-zero-downtime-fixed.yml
• Description: Full zero-downtime deployment with nginx load balancer
• Best for: Production deployments requiring high availability

Testing the Fixes

Local Testing

# Test the simplified deployment script
./scripts/gitea-deploy-simple.sh

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

Verification

# 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