TalentBricksAI implementa CI/CD usando GitHub Actions para garantizar calidad de código y facilitar el despliegue.

¿Qué es CI/CD?

CI (Continuous Integration): Integración continua - automatiza la verificación de código en cada cambio.

CD (Continuous Deployment): Despliegue continuo - automatiza el despliegue a staging y producción.

Estado Actual

✅ Fase 1: CI Básico (Build & Type Check) - ACTIVO

El pipeline de CI se ejecuta automáticamente en:

• Cada Pull Request hacia main (solo si cambia app/**)

Job 1: Lint, Type Check & Build

1. Checkout del código
2. Setup Node.js 22 con caché de dependencias
3. Instalación de Wasp CLI (v0.21.1)
4. Instalación de dependencias (npm ci)
5. Verificación de formato (Prettier)
6. Build de la aplicación (incluye type checking)
7. Build del cliente (compilación final)
8. Comentarios automáticos en PR (éxito/error)

Tiempo: ~2-3 minutos Estado: ✅ Funcionando correctamente

⏸️ Fase 2: Tests E2E Automatizados - PAUSADO

Estado actual: Código comentado en .github/workflows/ci.yml Razón: Problemas con inicio de Wasp app en ambiente de CI Tests locales: ✅ Funcionando perfectamente

Objetivo Original

Ejecutar tests E2E críticos automáticamente en cada PR para verificar:

• Autenticación y autorización
• Navegación entre páginas
• Funcionalidad de cursos
• Sistema de inscripciones

Lo Que Se Intentó

Se probaron dos aproximaciones diferentes para ejecutar tests E2E en CI:

Aproximación 1: Inicio Manual de Servidor (Build de Producción)

• Build completo de Wasp app (wasp build)
• Instalación de dependencias en .wasp/build/
• Inicio manual de servidor en background (puerto 3001)
• Inicio manual de cliente con Vite preview (puerto 3000)
• Health checks para verificar que ambos servicios estén activos
• Ejecución de tests Playwright

Aproximación 2: Playwright webServer (Modo Desarrollo)

• Uso de run-wasp-app dev vía Playwright webServer config
• Configuración en e2e-tests/playwright.config.ts
• Playwright maneja automáticamente inicio y cierre de la app
• Tests corren contra app en modo desarrollo (igual que local)

Problemas Encontrados

Aproximación 1: Inicio Manual

Problema principal: Homepage HTML completamente vacía

Síntomas:

- Health check pasa: ✓ Client is responding on port 3000
- curl http://localhost:3000 retorna HTML vacío
- Tests fallan: No encuentran login links ni elementos de UI
- Timeout después de 30 segundos buscando elementos

Diagnóstico:

• Vite preview server se inicia correctamente
• Puerto 3000 responde a requests HTTP
• Pero NO sirve ningún contenido (HTML vacío)
• Probablemente problema con build artifacts o configuración de Vite

Tests locales: ✅ Funcionan perfectamente Tests CI: ❌ Fallan consistentemente

Aproximación 2: Playwright webServer

Problema principal: webServer no puede iniciar la app

Error específico:

Error: Process from config.webServer was not able to start. Exit code: 1

Síntomas:

• Comando: run-wasp-app dev --path-to-app=../app --wasp-cli-cmd=wasp
• Proceso inicia pero termina inmediatamente con exit code 1
• No hay logs detallados del error
• Playwright espera que puerto 3001 responda pero nunca lo hace

Causa probable:

• webServer no tiene acceso a variables de entorno necesarias
• Wasp requiere ciertas env vars para iniciar (DATABASE_URL, etc.)
• Playwright webServer config no está pasando env vars al proceso

Tests locales: ✅ Funcionan (webServer inicia correctamente) Tests CI: ❌ webServer falla al iniciar

Diferencias Local vs CI

Aspecto	Local	CI
Entorno	Desarrollo con wasp start ya ejecutado antes	Ambiente limpio, sin archivos generados
Variables de entorno	Cargadas desde .env local	Solo las definidas en workflow YAML
Playwright webServer	Funciona correctamente	Exit code 1, no inicia
Build manual	No se usa (se usa dev server)	Genera archivos pero no sirve contenido
Base de datos	Puede tener estado previo	Siempre limpia con seed data
Timing	Sin problemas de performance	Potencialmente más lento

Trabajo Pendiente para Fase 2

Para reactivar tests E2E en CI, se necesita resolver:

1. Opción A: Fix Playwright webServer

   • Configurar env vars en playwright.config.ts para webServer
   • Pasar todas las variables necesarias al proceso
   • Verificar que run-wasp-app pueda iniciar con env vars desde config
   • Ventaja: Más simple, similar a local
   • Desventaja: Requiere modificar config de Playwright

2. Opción B: Fix inicio manual con Vite

   • Investigar por qué Vite preview no sirve contenido en CI
   • Verificar build artifacts están generándose correctamente
   • Posible problema con rutas absolutas vs relativas
   • Ventaja: Más control sobre el proceso
   • Desventaja: Más complejo, requiere más steps en workflow

3. Opción C: Usar wasp start directamente

   • Iniciar app con wasp start en background (modo dev)
   • Esperar que servidor esté listo
   • No usar webServer de Playwright
   • Similar a local pero sin webServer automation
   • Ventaja: Modo desarrollo completo
   • Desventaja: Requiere manejo manual de procesos

Archivos Relevantes

• Workflow CI: .github/workflows/ci.yml (Fase 2 comentada)
• Playwright Config: e2e-tests/playwright.config.ts (webServer config)
• Tests: e2e-tests/tests/*.spec.ts (100+ tests críticos)
• Documentación técnica: IMPLEMENTATION.md (sección “Test Infrastructure Consolidation”)

Cómo Ejecutar Tests Localmente

Los tests E2E funcionan perfectamente en local:

cd e2e-tests

# Opción 1: Con Playwright UI (recomendado para debugging)
npm run local:e2e:start

# Opción 2: Solo tests críticos
npm run e2e:critical

# Opción 3: Todos los tests
npm run e2e:playwright

Nota: Playwright webServer inicia automáticamente la app en local, no necesitas wasp start manual.

🚧 Próximamente (Fases 3 y 4)

• Fase 3: Deploy automático a staging
• Fase 4: Deploy manual a producción con aprobación
• Estrategia de rollback automático

Archivo de Configuración

El workflow está en .github/workflows/ci.yml:

Estado actual:

• ✅ Fase 1 (lint-and-build) - Activo
• ⏸️ Fase 2 (e2e-tests) - Comentado (ver sección de Fase 2 arriba)

name: CI

on:
  pull_request:
    branches: [main]
    paths:
      - "app/**"

# Cancel in-progress runs when a new run is triggered
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  # FASE 1: ACTIVO
  lint-and-build:
    name: Lint, Type Check & Build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
      pull-requests: write

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"

      - name: Install Wasp
        run: curl -sSL https://get.wasp-lang.dev/installer.sh | sh -s -- -v 0.20.0

      - name: Build Wasp app
        working-directory: ./app
        run: wasp build

      # ... más steps (ver archivo completo)

  # FASE 2: PAUSADO (COMENTADO EN EL ARCHIVO)
  # jobs:
  #   e2e-tests:
  #     ... (código preservado para futuro trabajo)

Nota: El archivo real tiene el código completo de ambas fases, con Fase 2 comentada.

Verificación Local

Antes de hacer push, puedes ejecutar las mismas verificaciones localmente:

Build y Type Check

# 1. Verificar formato
cd app
npx prettier --check "src/**/*.{ts,tsx,js,jsx,json,css}"

# 2. Arreglar formato automáticamente
npx prettier --write "src/**/*.{ts,tsx,js,jsx,json,css}"

# 3. Build (incluye type checking)
wasp build

# 4. Build del cliente
cd .wasp/build/web-app
npm run build

Tests E2E Críticos

# Asegúrate de que la app esté corriendo
cd app
wasp db start    # Terminal 1
wasp start       # Terminal 2

# Corre tests críticos (mismos que el CI)
cd e2e-tests
npm run e2e:critical

# O todos los tests
npm run e2e:playwright

Tip: Los tests críticos toman ~3-5 min localmente vs ~5-7 min en CI (overhead de setup).

Reglas de Protección

Para activar protección de branch en GitHub:

1. Ve a Settings → Branches
2. Agrega regla para main:
   • ✅ Require pull request before merging
   • ✅ Require status checks to pass (selecciona Lint, Type Check & Build)
   • ✅ Require branches to be up to date

Esto previene merges que rompan el build.

Badge de Status

El README principal incluye un badge que muestra el estado del CI:

[![CI](https://github.com/talentoparati/talentbricks-ai/actions/workflows/ci.yml/badge.svg)](https://github.com/talentoparati/talentbricks-ai/actions/workflows/ci.yml)

Troubleshooting

El CI falla con “Wasp not found”

Solución: Verificar que el PATH incluya $HOME/.local/bin:

- name: Add Wasp to PATH
  run: echo "$HOME/.local/bin" >> $GITHUB_PATH

El CI falla con “Module not found”

Solución: Asegurarse de instalar dependencias en el directorio correcto:

- name: Install dependencies
  working-directory: ./app
  run: npm ci

El formato de Prettier falla

Solución: Ejecutar localmente antes de push:

cd app
npx prettier --write "src/**/*.{ts,tsx,js,jsx,json,css}"
git add -A
git commit -m "Fix: formato de código"

Build falla por errores de TypeScript

Solución: Ejecutar localmente para ver errores detallados:

cd app
wasp build
# Errores aparecerán en la consola

Tests E2E fallan en CI pero pasan localmente

Estado actual: ⏸️ Fase 2 está pausada debido a este problema

Ver sección “Fase 2: Tests E2E Automatizados - PAUSADO” arriba para:

• Detalles completos del problema
• Aproximaciones intentadas
• Diagnóstico de errores
• Opciones para resolver en el futuro

Resumen del problema:

• Playwright webServer no puede iniciar la app en CI (exit code 1)
• Probablemente falta configuración de variables de entorno en webServer
• Tests locales funcionan perfectamente ✅

Posibles causas adicionales (si reactivamos):

1. Timing issues - El CI puede ser más lento:

// Aumentar timeouts en playwright.config.ts
timeout: 60000; // 60 segundos

2. Datos de prueba - Verificar que el seed corrió correctamente:

# Ver logs del servidor en CI
gh run view <run-id> --log

3. Variables de entorno - Asegurar que SKIP_EMAIL_VERIFICATION_IN_DEV=true

Uso de Minutos de GitHub Actions

Límite Free Tier (Repos Privados)

• 2,000 minutos/mes gratis
• Después: $0.008/minuto

Consumo Estimado

Fase	Tiempo/run	30 PRs/mes	% del límite
Fase 1 (Build)	3 min	90 min	4.5% ✅
Fase 2 (+E2E)	10 min	300 min	15% ✅
Ambas fases	Total	300 min	15% ✅

Conclusión: Con actividad normal (30 PRs/mes), usarás solo 15% del límite gratuito.

Optimizaciones Implementadas

✅ Path filtering - Solo corre si cambias app/** ✅ Concurrency control - Cancela runs viejos automáticamente ✅ Tests selectivos - Solo tests críticos (~100 de 362) ✅ Caché de npm - Reduce tiempo de instalación ✅ Workers paralelos - Playwright usa 2 workers

Monitorear Uso

GitHub → Settings → Billing → Actions usage
https://github.com/settings/billing

Tests Críticos vs Todos los Tests

Tests Críticos (CI)

Definidos en e2e-tests/package.json:

"e2e:critical": "npx playwright test authTests.spec.ts navigationTests.spec.ts coursesTests.spec.ts enrollmentTests.spec.ts --workers=2"

Incluye:

• ✅ Autenticación (18 tests)
• ✅ Navegación (34 tests)
• ✅ Cursos (20 tests)
• ✅ Inscripciones (20 tests)
• Total: ~92 tests críticos

Todos los Tests (Local)

npm run e2e:playwright

Total: 362 tests (~15 min)

¿Por qué no correr todos en CI?

• Consumo de minutos: 15 min × 30 PRs = 450 min/mes (22.5%)
• Tests lentos (payment, demo-ai-app) tienen timeouts
• Tests críticos cubren 80% de funcionalidad core

Próximos Pasos (Fases 3 y 4)

Fase 3: Deploy Automático a Staging

• Auto-deploy en cada merge a main
• Smoke tests post-deployment
• Notificaciones en Slack

Fase 4: Deploy a Producción

• Aprobación manual requerida
• Blue-green deployment
• Rollback automático en caso de fallo
• Zero-downtime migrations

Referencias

• GitHub Actions Docs
• Wasp Deployment
• Prettier CLI