name: Continuous Integration

# This workflow triggers on two events:
# 1. When code is pushed to main branch
# 2. When a pull request targets main branch
# Why these triggers? They catch issues early in the development process
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    # Why ubuntu-latest? It's free, fast, and has excellent tool support
    # Alternatives: windows-latest, macos-latest (but cost more)
    runs-on: ubuntu-latest
    
    # Node.js versions to test against
    # Why matrix testing? Ensures compatibility across versions your users might have
    strategy:
      matrix:
        node-version: [16.x, 18.x, 20.x]
    
    steps:
    # Check out the repository code
    # Why v3? It's the latest stable version with security improvements
    - uses: actions/checkout@v3
    
    # Set up Node.js environment
    - name: Use Node.js $
      uses: actions/setup-node@v3
      with:
        node-version: $
        
    # Cache dependencies for faster builds
    # Why cache? npm install can take 30-60 seconds; caching reduces this to 5-10 seconds
    - name: Cache dependencies
      uses: actions/cache@v3
      with:
        path: ~/.npm
        # Why hash the lock file? Cache is invalidated only when dependencies change
        key: $-node-$
        restore-keys: |
          $-node-
    
    # Install project dependencies
    # Why npm ci instead of npm install? It's faster and more reliable for CI environments
    - name: Install dependencies
      run: npm ci
    
    # Run linting to check code style
    # Why lint first? Code style issues are faster to check than running full test suite
    - name: Run linter
      run: npm run lint
    
    # Run unit tests
    # Why after linting? No point running tests if code doesn't meet style standards
    - name: Run tests
      run: npm test
    
    # Generate test coverage report
    # Why coverage? Helps identify untested code and technical debt
    - name: Generate coverage report
      run: npm run test:coverage

jobs:
  test:
    runs-on: ubuntu-latest
    
    # Service containers run alongside your job
    # Why alongside? They share the same network, making connection simple
    services:
      postgres:
        image: postgres:14  # Why version 14? It's stable, widely supported, and matches our production
        env:
          POSTGRES_USER: testuser
          POSTGRES_PASSWORD: testpass
          POSTGRES_DB: testdb
        # Health checks ensure the database is ready
        # Why health checks? Database startup can take 10-30 seconds
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          # Why port mapping? Makes the service accessible to our test jobs
          - 5432:5432
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Use Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18.x'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run tests with database
      env:
        # These environment variables are used by our app
        # Why environment variables? They keep secrets out of code and enable different configs per environment
        DATABASE_URL: postgresql://testuser:testpass@localhost:5432/testdb
        NODE_ENV: test
      run: npm test

name: Deploy to AWS

# Why only on main branch pushes? We want to deploy only tested, approved code
on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    - name: Use Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18.x'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run tests
      run: npm test
    
    # Only proceed to build job if tests pass
    # This creates a gate in our pipeline
    
  build:
    needs: test  # This job depends on 'test' job success
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    - name: Use Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18.x'
    
    - name: Install production dependencies
      # Why --only=production? Smaller package, faster deploys, fewer security vulnerabilities
      run: npm ci --only=production
    
    - name: Build application
      run: npm run build
    
    # Create deployment artifact
    - name: Create deployment package
      run: |
        # Remove development files
        rm -rf .git .github test coverage docs
        
        # Create timestamp for versioning
        echo "DEPLOY_VERSION=$(date +%Y%m%d%H%M%S)" >> $GITHUB_ENV
        
        # Package application
        tar -czf deploy-$.tar.gz .
    
    # Upload artifact for deployment job
    # Why separate build and deploy jobs? Enables different runners, security boundaries
    - name: Upload deployment artifact
      uses: actions/upload-artifact@v3
      with:
        name: deploy-package
        path: deploy-*.tar.gz
        retention-days: 7
  
  deploy:
    needs: build
    runs-on: ubuntu-latest
    # Only deploy from main branch
    if: github.ref == 'refs/heads/main'
    
    steps:
    - name: Download deployment artifact
      uses: actions/download-artifact@v3
      with:
        name: deploy-package
    
    # Configure AWS credentials
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
        aws-access-key-id: $
        aws-secret-access-key: $
        aws-region: $
    
    # Upload to S3 first (backup and staging)
    # Why S3 first? Creates a backup, enables multi-server deployments, provides audit trail
    - name: Upload to S3
      run: |
        DEPLOY_FILE=$(ls deploy-*.tar.gz)
        aws s3 cp $DEPLOY_FILE s3://your-deployment-bucket/releases/
        echo "DEPLOY_FILE=$DEPLOY_FILE" >> $GITHUB_ENV
    
    # Deploy to EC2
    - name: Deploy to EC2
      env:
        PRIVATE_KEY: $
      run: |
        # Save private key
        echo "$PRIVATE_KEY" > private_key
        chmod 600 private_key
        
        # Create deployment script
        cat > deploy.sh << 'EOF'
        #!/bin/bash
        set -e  # Exit on error
        
        # Variables
        DEPLOY_FILE=$1
        APP_DIR=/home/ubuntu/app
        BACKUP_DIR=/home/ubuntu/backups
        
        # Create backup of current deployment
        if [ -d "$APP_DIR" ]; then
          echo "Creating backup..."
          sudo mkdir -p $BACKUP_DIR
          sudo tar -czf $BACKUP_DIR/backup-$(date +%Y%m%d%H%M%S).tar.gz -C $APP_DIR .
          
          # Keep only last 5 backups
          sudo find $BACKUP_DIR -name "backup-*.tar.gz" -type f | sort -r | tail -n +6 | sudo xargs -r rm
        fi
        
        # Download new version from S3
        echo "Downloading new version..."
        aws s3 cp s3://your-deployment-bucket/releases/$DEPLOY_FILE /tmp/
        
        # Extract new version
        echo "Extracting application..."
        sudo mkdir -p $APP_DIR
        sudo rm -rf $APP_DIR/*
        sudo tar -xzf /tmp/$DEPLOY_FILE -C $APP_DIR
        
        # Install dependencies and build
        cd $APP_DIR
        sudo npm ci --only=production
        
        # Run database migrations
        echo "Running migrations..."
        NODE_ENV=production npm run migrate
        
        # Restart application using PM2
        echo "Restarting application..."
        pm2 restart ecosystem.config.js --update-env
        
        # Health check
        echo "Performing health check..."
        sleep 10
        
        # Try health check with retries
        for i in {1..5}; do
          if curl -f http://localhost:3000/health; then
            echo "Health check passed!"
            break
          else
            echo "Health check attempt $i failed, retrying..."
            sleep 5
          fi
          
          if [ $i -eq 5 ]; then
            echo "Health check failed after 5 attempts"
            exit 1
          fi
        done
        
        echo "Deployment successful!"
        EOF
        
        # Execute deployment
        ssh -o StrictHostKeyChecking=no -i private_key \
          $@$ \
          'bash -s' < deploy.sh $
        
        # Cleanup
        rm -f private_key deploy.sh
    
    # Notify team of deployment
    - name: Send deployment notification
      if: always()  # Run even if deployment fails
      run: |
        if [ "$" == "success" ]; then
          MESSAGE="✅ Deployment successful to production"
          COMMIT_MSG=$(git log -1 --pretty=format:"%s")
          AUTHOR=$(git log -1 --pretty=format:"%an")
        else
          MESSAGE="❌ Deployment failed to production"
          COMMIT_MSG="Failed deployment"
          AUTHOR="GitHub Actions"
        fi
        
        echo "Status: $MESSAGE"
        echo "Commit: $COMMIT_MSG"
        echo "Author: $AUTHOR"
        
        # You can integrate with Slack, Discord, Microsoft Teams, etc.
        # Example Slack webhook:
        # curl -X POST -H 'Content-type: application/json' \
        #   --data "{\"text\":\"$MESSAGE\\nCommit: $COMMIT_MSG\\nAuthor: $AUTHOR\"}" \
        #   $

name: Deploy to Multiple Environments

on:
  push:
    branches:
      - main        # Production deployment
      - develop     # Staging deployment
      - 'release/*' # Release candidate testing

jobs:
  determine-environment:
    runs-on: ubuntu-latest
    outputs:
      environment: $
    steps:
    - name: Determine deployment environment
      id: determine
      run: |
        # Why this logic? Different branches represent different stages of code maturity
        if [[ "$" == "refs/heads/main" ]]; then
          echo "environment=production" >> $GITHUB_OUTPUT
        elif [[ "$" == "refs/heads/develop" ]]; then
          echo "environment=staging" >> $GITHUB_OUTPUT
        else
          echo "environment=development" >> $GITHUB_OUTPUT
        fi
  
  deploy:
    needs: determine-environment
    runs-on: ubuntu-latest
    # Why environment gates? GitHub provides manual approval and protection rules
    environment: $
    steps:
    - uses: actions/checkout@v3
    
    # Environment-specific secrets are automatically available
    # Why automatic? GitHub manages secret scoping by environment
    - name: Deploy to $
      run: |
        echo "Deploying to $"
        echo "Using server: $"
        echo "Using database: $"
        # Your deployment logic here

name: Rollback Deployment

# Why workflow_dispatch? Manual trigger for emergency situations
on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Version to rollback to (e.g., 20231125120000)'
        required: true
        type: string
      environment:
        description: 'Environment to rollback'
        required: true
        type: choice
        options:
          - production
          - staging

jobs:
  rollback:
    runs-on: ubuntu-latest
    environment: $
    steps:
    - name: Validate version exists
      run: |
        # Check if version exists in S3
        aws s3 ls s3://your-deployment-bucket/releases/deploy-$.tar.gz || {
          echo "❌ Version $ not found!"
          exit 1
        }
    
    - name: Rollback to version $
      env:
        PRIVATE_KEY: $
      run: |
        # Save private key
        echo "$PRIVATE_KEY" > private_key
        chmod 600 private_key
        
        # Create rollback script
        cat > rollback.sh << 'EOF'
        #!/bin/bash
        set -e
        
        VERSION=$1
        APP_DIR=/home/ubuntu/app
        FAILED_DIR=/home/ubuntu/failed-deployments
        
        # Why capture failed deployment? Helps with post-incident analysis
        echo "Capturing failed deployment for analysis..."
        sudo mkdir -p $FAILED_DIR
        sudo tar -czf $FAILED_DIR/failed-$(date +%Y%m%d%H%M%S).tar.gz -C $APP_DIR .
        
        # Download specified version
        echo "Downloading version $VERSION..."
        aws s3 cp s3://your-deployment-bucket/releases/deploy-$VERSION.tar.gz /tmp/
        
        # Extract rollback version
        echo "Extracting rollback version..."
        sudo rm -rf $APP_DIR/*
        sudo tar -xzf /tmp/deploy-$VERSION.tar.gz -C $APP_DIR
        
        # Restore application
        cd $APP_DIR
        sudo npm ci --only=production
        
        # Check if database rollback is needed
        # Why manual check? Database rollbacks are riskier and need careful consideration
        echo "⚠️  WARNING: This rollback may require database changes"
        echo "Please verify database compatibility manually if needed"
        
        # Restart application
        pm2 restart ecosystem.config.js --update-env
        
        # Health check with longer timeout for rollbacks
        echo "Performing health check..."
        sleep 10
        
        for i in {1..10}; do
          if curl -f http://localhost:3000/health; then
            echo "✅ Rollback health check passed!"
            break
          else
            echo "⏳ Health check attempt $i failed, retrying..."
            sleep 5
          fi
          
          if [ $i -eq 10 ]; then
            echo "❌ Rollback health check failed after 10 attempts"
            echo "Manual intervention required!"
            exit 1
          fi
        done
        
        echo "🎉 Rollback to version $VERSION successful!"
        EOF
        
        # Execute rollback
        ssh -o StrictHostKeyChecking=no -i private_key \
          $@$ \
          'bash -s' < rollback.sh $
        
        # Cleanup
        rm -f private_key rollback.sh
    
    # Post-rollback notification
    - name: Notify team of rollback
      run: |
        MESSAGE="🔄 Rollback completed to version $ on $"
        echo "$MESSAGE"
        
        # Post to incident management system
        # Example: PagerDuty, Opsgenie, or internal systems

- name: Post-deployment monitoring
  run: |
    # Function to check endpoint
    check_endpoint() {
      local url=$1
      local expected_status=$2
      local max_attempts=10
      local attempt=0
      
      echo "🔍 Checking $url (expecting $expected_status)"
      
      while [ $attempt -lt $max_attempts ]; do
        # Why curl flags? -s (silent), -o /dev/null (ignore body), -w (write out format)
        response=$(curl -s -o /dev/null -w "%{http_code},%{time_total},%{size_download}" $url)
        status=$(echo $response | cut -d',' -f1)
        time_total=$(echo $response | cut -d',' -f2)
        size=$(echo $response | cut -d',' -f3)
        
        if [ "$status" = "$expected_status" ]; then
          echo "✅ $url returned $status in ${time_total}s (${size} bytes)"
          return 0
        fi
        
        echo "⏳ $url returned $status (expected $expected_status), attempt $((attempt + 1))/$max_attempts"
        attempt=$((attempt + 1))
        sleep 5
      done
      
      echo "❌ $url failed after $max_attempts attempts"
      return 1
    }
    
    echo "🩺 Starting post-deployment health checks..."
    
    # Check critical endpoints
    check_endpoint "https://api.example.com/health" "200"
    check_endpoint "https://api.example.com/api/v1/status" "200"
    check_endpoint "https://api.example.com/api/v1/users/me" "401"  # Should require auth
    
    echo "⏱️  Measuring performance..."
    
    # Check response times
    response_time=$(curl -s -o /dev/null -w "%{time_total}" https://api.example.com/health)
    echo "Health check response time: ${response_time}s"
    
    # Alert if response time is too high
    if (( $(echo "$response_time > 2.0" | bc -l) )); then
      echo "⚠️  WARNING: High response time detected! (${response_time}s > 2.0s)"
      
      # Send alert to monitoring system
      # Example: Post to Slack, PagerDuty, or custom monitoring
      curl -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"🚨 High response time after deployment: ${response_time}s\"}" \
        $ || echo "Failed to send alert"
    fi
    
    # Check database connection
    echo "🗄️  Checking database connectivity..."
    ssh -o StrictHostKeyChecking=no -i private_key \
      $@$ \
      'cd /home/ubuntu/app && npm run db:check' || {
      echo "❌ Database connectivity check failed"
      exit 1
    }
    
    # Check memory usage
    echo "💾 Checking system resources..."
    memory_usage=$(ssh -o StrictHostKeyChecking=no -i private_key \
      $@$ \
      "free | grep Mem | awk '{printf \"%.0f\", \$3/\$2 * 100.0}'")
    
    echo "Memory usage: ${memory_usage}%"
    
    if [ "$memory_usage" -gt 85 ]; then
      echo "⚠️  WARNING: High memory usage detected! (${memory_usage}% > 85%)"
    fi
    
    echo "✅ Post-deployment monitoring completed"

- name: Run security audit
  run: |
    echo "🔍 Scanning for known vulnerabilities..."
    
    # Check for known vulnerabilities - Why npm audit? Built into npm, checks against npm security database
    npm audit --production
    
    # For more strict checking (fails on any vulnerability)
    # Uncomment the line below for zero-tolerance security policy
    # npm audit --production --audit-level=low
    
    # Generate detailed audit report
    npm audit --json > audit-report.json || true
    
    # Parse and display critical vulnerabilities
    if command -v jq &> /dev/null; then
      echo "🚨 Critical vulnerabilities found:"
      jq '.vulnerabilities | to_entries[] | select(.value.severity == "critical") | {package: .key, severity: .value.severity, title: .value.title}' audit-report.json
    fi

- name: Run Snyk security scan
  uses: snyk/actions/node@master
  env:
    SNYK_TOKEN: $
  with:
    # Why severity threshold? Focus on actionable vulnerabilities
    args: --severity-threshold=high
    # Generate reports for security team review
    json: true
    sarif: true

- name: Upload Snyk results to GitHub Security tab
  uses: github/codeql-action/upload-sarif@v2
  if: always()
  with:
    sarif_file: snyk.sarif

- name: Scan for secrets
  uses: trufflesecurity/trufflehog@main
  with:
    path: ./
    base: $
    head: HEAD
    # Why these options? Balance between thoroughness and false positives
    extra_args: --debug --only-verified

- name: GitLeaks secret scan
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: $
  with:
    # Why fail on detection? Prevent secrets from entering the codebase
    fail: true

- name: Build Docker image
  run: |
    # Build with specific tag for tracking
    docker build -t $:$ .
    docker build -t $:latest .

- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: '$:$'
    format: 'sarif'
    output: 'trivy-results.sarif'
    # Why these severities? Focus on actionable vulnerabilities
    severity: 'MEDIUM,HIGH,CRITICAL'
    # Why ignore unfixed? Can't do anything about them anyway
    ignore-unfixed: true

- name: Upload Trivy scan results
  uses: github/codeql-action/upload-sarif@v2
  if: always()
  with:
    sarif_file: 'trivy-results.sarif'

- name: Docker Scout scan
  uses: docker/scout-action@v1
  with:
    command: cves
    image: $:$
    # Why exit on vulnerabilities? Prevent vulnerable images from being deployed
    exit-code: true
    only-severities: critical,high

- name: Initialize CodeQL
  uses: github/codeql-action/init@v2
  with:
    languages: javascript
    # Why specify queries? Focus on security-related issues
    queries: security-extended

- name: Perform CodeQL Analysis
  uses: github/codeql-action/analyze@v2
  with:
    category: "/language:javascript"

- name: Debug information
  if: failure()  # Why only on failure? Reduces noise in successful runs
  run: |
    echo "🐛 Debug Information for Failed Workflow"
    echo "======================================"
    echo "Event: $"
    echo "Ref: $"
    echo "SHA: $"
    echo "Actor: $"
    echo "Workflow: $"
    echo "Job: $"
    echo "Run ID: $"
    echo "Run Number: $"
    
    # Show environment variables (be careful with secrets!)
    echo ""
    echo "🌍 Environment Variables (filtered):"
    env | grep -v SECRET | grep -v TOKEN | grep -v KEY | sort
    
    # Show runner information
    echo ""
    echo "🖥️  Runner Information:"
    echo "Runner OS: $"
    echo "Runner Arch: $"
    echo "Runner Temp: $"
    echo "Runner Tool Cache: $"
    
    # Show disk space (common issue)
    echo ""
    echo "💾 Disk Usage:"
    df -h
    
    # Show system resources
    echo ""
    echo "⚡ System Resources:"
    free -h

- name: Setup tmate session for debugging
  # Why only on manual trigger? Prevents accidental exposure of debugging sessions
  if: $
  uses: mxschmitt/action-tmate@v3
  with:
    # Why limit access? Security - only the workflow triggerer can access
    limit-access-to-actor: true
    # Why timeout? Prevents sessions from running indefinitely
    timeout-minutes: 30

- name: Upload logs on failure
  if: failure()
  uses: actions/upload-artifact@v3
  with:
    name: debug-logs-$
    path: |
      /tmp/debug.log
      ~/.npm/_logs/
      $
    retention-days: 7

- name: Debug SSH connection
  if: failure()
  run: |
    echo "🔧 Debugging SSH Connection Issues"
    echo "================================"
    
    # Test basic connectivity
    echo "🌐 Testing network connectivity..."
    ping -c 4 $ || echo "❌ Ping failed - check security groups and network"
    
    # Test SSH port
    echo ""
    echo "🔌 Testing SSH port 22..."
    timeout 10 nc -zv $ 22 || echo "❌ Port 22 not accessible - check security groups"
    
    # Check if host key has changed
    echo ""
    echo "🔑 Testing SSH host key..."
    ssh-keyscan -H $ 2>/dev/null || echo "❌ SSH host key scan failed"
    
    # Verbose SSH attempt (remove sensitive key content from logs)
    echo ""
    echo "🐛 Verbose SSH connection test..."
    echo "$" > private_key
    chmod 600 private_key
    
    # Why timeout? Prevents hanging on failed connections
    timeout 30 ssh -vvv -o StrictHostKeyChecking=no -o ConnectTimeout=10 -i private_key \
      $@$ \
      'echo "✅ SSH connection successful"' 2>&1 | head -50 || {
      echo "❌ SSH connection failed"
      echo ""
      echo "Common solutions:"
      echo "1. Check EC2 security group allows SSH (port 22) from GitHub Actions IPs"
      echo "2. Verify EC2 instance is running and accessible"
      echo "3. Check SSH key format and permissions"
      echo "4. Ensure EC2_USER is correct (ubuntu for Ubuntu, ec2-user for Amazon Linux)"
    }
    
    rm -f private_key
    
    # Check GitHub Actions IP ranges
    echo ""
    echo "📡 GitHub Actions IP ranges (for security group configuration):"
    curl -s https://api.github.com/meta | jq -r '.actions[]' 2>/dev/null || echo "Failed to fetch GitHub IPs"

- name: Test EC2 instance status
  if: failure()
  run: |
    echo "🖥️  Checking EC2 instance status..."
    
    # This requires EC2 permissions in your IAM policy
    aws ec2 describe-instances \
      --filters "Name=ip-address,Values=$" \
      --query 'Reservations[*].Instances[*].[InstanceId,State.Name,PublicIpAddress]' \
      --output table || echo "Failed to get EC2 status (check AWS permissions)"

# Parallel job execution - Why? Reduce total pipeline time
jobs:
  tests:
    strategy:
      # Why matrix? Run different test suites in parallel
      matrix:
        test-suite: [unit, integration, e2e]
        node-version: [16, 18, 20]
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Setup Node.js $
      uses: actions/setup-node@v3
      with:
        node-version: $
    - name: Run $ tests
      run: npm run test:$
  
  # Jobs run in parallel by default - Why? Maximize resource utilization
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run linting
      run: npm run lint
  
  security-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run security scan
      run: npm audit

  # Conditional jobs - Why? Skip unnecessary work
  deploy:
    needs: [tests, lint, security-scan]
    # Only run on main branch pushes
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
    - name: Deploy
      run: echo "Deploying..."

# Advanced caching strategy
- name: Cache multiple dependencies
  uses: actions/cache@v3
  with:
    path: |
      ~/.npm
      ~/.cache
      node_modules
      # Why cache node_modules? npm ci can be slow even with cache
    # Why complex key? Ensures cache invalidation when any dependency changes
    key: $-node-$-$
    restore-keys: |
      $-node-$-
      $-node-

# Docker layer caching - Why? Docker builds can be very slow
- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v2

- name: Build and cache Docker image
  uses: docker/build-push-action@v4
  with:
    context: .
    push: false
    tags: myapp:latest
    # Why GitHub Actions cache? Free and automatic
    cache-from: type=gha
    cache-to: type=gha,mode=max

# Database caching for tests
- name: Cache test database
  uses: actions/cache@v3
  with:
    path: /tmp/test-db
    key: test-db-$
  
# Warm up cache in separate job
warm-cache:
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v3
  - name: Warm dependency cache
    uses: actions/cache@v3
    with:
      path: ~/.npm
      key: $-node-$
  - run: npm ci

name: Pipeline Metrics

# Why workflow_run trigger? Captures data after each pipeline execution
on:
  workflow_run:
    workflows: ["Deploy to AWS", "Continuous Integration"]
    types: [completed]

jobs:
  collect-metrics:
    runs-on: ubuntu-latest
    steps:
    - name: Calculate and store metrics
      uses: actions/github-script@v6
      with:
        github-token: $
        script: |
          const workflow_run = context.payload.workflow_run;
          
          // Calculate duration - Why important? Track performance trends
          const started = new Date(workflow_run.created_at);
          const completed = new Date(workflow_run.updated_at);
          const duration = (completed - started) / 1000 / 60; // minutes
          
          // Extract useful information
          const metrics = {
            workflow_name: workflow_run.name,
            status: workflow_run.conclusion,
            duration_minutes: Math.round(duration * 100) / 100,
            branch: workflow_run.head_branch,
            commit_sha: workflow_run.head_sha.substring(0, 7),
            author: workflow_run.triggering_actor.login,
            timestamp: completed.toISOString(),
            attempt: workflow_run.run_attempt,
            event: workflow_run.event
          };
          
          console.log('📊 Pipeline Metrics:');
          console.log(`Workflow: ${metrics.workflow_name}`);
          console.log(`Status: ${metrics.status}`);
          console.log(`Duration: ${metrics.duration_minutes} minutes`);
          console.log(`Branch: ${metrics.branch}`);
          console.log(`Author: ${metrics.author}`);
          console.log(`Attempt: ${metrics.attempt}`);
          
          // Store in repository (simple approach)
          try {
            const metricsFile = `metrics/${new Date().toISOString().split('T')[0]}.json`;
            
            // Try to get existing metrics for today
            let existingMetrics = [];
            try {
              const { data: fileData } = await github.rest.repos.getContent({
                owner: context.repo.owner,
                repo: context.repo.repo,
                path: metricsFile
              });
              existingMetrics = JSON.parse(Buffer.from(fileData.content, 'base64').toString());
            } catch (error) {
              // File doesn't exist yet, that's okay
            }
            
            // Add new metrics
            existingMetrics.push(metrics);
            
            // Store updated metrics
            const content = Buffer.from(JSON.stringify(existingMetrics, null, 2)).toString('base64');
            
            await github.rest.repos.createOrUpdateFileContents({
              owner: context.repo.owner,
              repo: context.repo.repo,
              path: metricsFile,
              message: `Update pipeline metrics for ${metrics.workflow_name}`,
              content: content,
              sha: fileData?.sha // Include SHA if file exists
            });
            
          } catch (error) {
            console.log('Failed to store metrics:', error.message);
          }
          
          // Alert on failures or slow builds
          if (metrics.status === 'failure') {
            console.log('🚨 Build failed! Consider alerting the team.');
          }
          
          if (metrics.duration_minutes > 10) {
            console.log(`⚠️ Slow build detected: ${metrics.duration_minutes} minutes`);
          }

- name: Send metrics to CloudWatch
  run: |
    # Send deployment event to CloudWatch
    aws cloudwatch put-metric-data \
      --namespace "GitHubActions/Deployments" \
      --metric-data \
        MetricName=DeploymentDuration,Value=$,Unit=Seconds \
        MetricName=DeploymentSuccess,Value=1,Unit=Count
    
    # Create deployment marker in CloudWatch Insights
    aws logs put-log-events \
      --log-group-name "/aws/lambda/deployment-events" \
      --log-stream-name "deployments" \
      --log-events \
        timestamp=$(date +%s)000,message='{"event":"deployment","status":"success","commit":"$","duration":$}'