GitHub Actions: Automatización de Workflows

Los workflows son archivos YAML en .github/workflows/. Cada workflow tiene un nombre, condiciones de trigger (on), y uno o más jobs que corren en runners hosted por GitHub o self-hosted. Los triggers incluyen push, pull_request, schedule (cron), workflow_dispatch (manual), repository_dispatch (API) y docenas de eventos webhook (comentarios en issues, releases, deployments). Un solo repositorio puede tener workflows ilimitados.

Filtra triggers con precisión: on: push: branches: [main] corre solo en pushes a main. on: pull_request: paths: ['src/**'] corre solo cuando cambian archivos fuente. on: schedule: - cron: '0 6 * * 1' corre cada lunes a las 6 AM UTC. Combina triggers: un workflow puede dispararse tanto en push a main como en dispatch manual, con comportamiento diferente según el evento trigger usando github.event_name.

Los jobs corren en paralelo por defecto. Usa needs para crear dependencias secuenciales: deploy: needs: [test, build] espera a que tanto test como build tengan éxito. Cada job corre en una instancia de runner fresca sin estado compartido — pasa datos entre jobs vía artifacts o outputs de job. Los grupos de concurrencia (concurrency: { group: deploy-prod, cancel-in-progress: true }) previenen deployments duplicados.

El Marketplace de GitHub Actions hostea miles de actions reutilizables para tareas comunes de CI/CD. En vez de scriptear builds Docker, deployments Kubernetes o notificaciones de Slack desde cero, usa actions de la comunidad u oficiales. Pina actions a una versión específica (uses: actions/checkout@v7) o SHA (uses: actions/checkout@abc123) para reproducibilidad y seguridad — nunca uses @main o @latest en workflows de producción.

Actions oficiales esenciales: actions/checkout (clonar el repo), actions/setup-node (instalar Node.js con caching), actions/cache (cachear dependencias), actions/upload-artifact y actions/download-artifact (compartir archivos entre jobs), y github/codeql-action (análisis de seguridad). Actions Docker como docker/build-push-action manejan builds de imágenes multi-plataforma con BuildKit y cache de capas.

Crea actions custom de tres formas: actions JavaScript (arranque más rápido, corren directamente en Node.js), actions de contenedor Docker (cualquier lenguaje, ambiente aislado), y actions composite (secuencias reutilizables de steps definidas en YAML). Las actions composite son las más simples de crear y mantener — son simplemente steps de workflow empaquetados en una unidad reutilizable con inputs y outputs.

Los matrix builds corren el mismo job con diferentes combinaciones de variables. Define una matrix de versiones de Node.js, sistemas operativos, o cualquier variable custom, y GitHub Actions genera un job por cada combinación. Esto es esencial para testear compatibilidad de librerías entre ambientes: testea en Node 20, 22 y 24 en Ubuntu, macOS y Windows con una sola definición de workflow.

La clave strategy.matrix define las variables. include agrega combinaciones específicas con variables extra, y exclude remueve combinaciones no deseadas. Configura fail-fast: false para correr todas las combinaciones de la matrix aunque una falle — útil cuando necesitas resultados completos de test en todas las plataformas. max-parallel limita jobs concurrentes para no sobrecargar servicios externos.

Para matrices grandes, usa generación dinámica de matrix: un job de setup genera la matrix como output JSON, y el job de test usa fromJSON(needs.setup.outputs.matrix) para consumirla. Este patrón habilita matrices definidas por contenido de archivos (ej: testear cada paquete en un monorepo) o datos externos (ej: testear cada versión de base de datos soportada).

Los Secrets de GitHub almacenan valores sensibles (API keys, tokens, credenciales) encriptados y solo expuestos a workflows en runtime. Los secrets están disponibles a nivel de repositorio, organización y ambiente. Accedelos en workflows con ${{ secrets.MY_SECRET }}. GitHub automáticamente redacta valores de secrets de los logs de workflow, pero ten cuidado con comandos que podrían filtrarlos (ej: echo o logging de debug).

Los ambientes definen targets de deployment (staging, producción) con reglas de protección: reviewers requeridos, timers de espera, restricciones de rama y políticas de rama de deployment. Los secrets de ambiente solo están disponibles para jobs que apuntan a ese ambiente. Esto provee un límite de seguridad fuerte — las credenciales de base de datos de producción solo son accesibles al job deploy-production, no a jobs de test corriendo en pull requests.

Para autenticación OIDC (sin password), GitHub Actions puede asumir roles de proveedores cloud directamente usando aws-actions/configure-aws-credentials o google-github-actions/auth con federación de identidad de workload. Esto elimina claves de service account de larga vida almacenadas como secrets. El workflow solicita un token de corta vida al proveedor OIDC de GitHub, y el proveedor cloud lo valida contra el repositorio y workflow. Este es el estándar de oro para autenticación cloud en CI/CD.

La Claude Code GitHub Action (anthropics/claude-code-action) trae review de código y automatización potenciada por AI directamente a tu workflow de pull request de GitHub. Cuando se abre o actualiza un PR, la action ejecuta Claude Code en modo headless, analizando el diff, buscando bugs, sugiriendo mejoras y posteando comentarios de review — todo automáticamente sin intervención humana.

La configuración es directa: agrega la action a un workflow disparado por eventos pull_request, provee tu API key de Anthropic como secret, y opcionalmente especifica un prompt custom o archivo CLAUDE.md. La action lee el diff del PR, entiende el contexto de los cambios, y postea comentarios inline en líneas específicas o un comentario de review resumen. Puede aprobar, solicitar cambios o dejar comentarios neutrales basados en los hallazgos.

Casos de uso avanzados incluyen: review de código automatizado con estándares específicos del proyecto (apuntando a un archivo CLAUDE.md), auditoría de seguridad de cambios del PR, generación de documentación para funciones nuevas, sugerencia de tests para caminos de código sin cobertura, y escritura automática de descripción del PR. La action soporta prompts custom, permitiendo a los equipos aplicar criterios de review específicos como "chequea inyección SQL" o "verifica manejo de errores en todos los endpoints nuevos."

Cachear dependencias es la optimización de velocidad más grande para workflows. La action actions/cache almacena y restaura directorios entre ejecuciones de workflow. Para Node.js, cachea ~/.npm (el directorio de cache de npm) con clave basada en el hash de package-lock.json. Para Python, cachea ~/.cache/pip. Para Go, cachea ~/go/pkg/mod. Un cache hit ahorra 30-120 segundos por job al saltar descarga y extracción de dependencias.

Las actions de setup frecuentemente incluyen caching integrado: actions/setup-node@v7 con cache: npm automáticamente cachea y restaura el cache global de npm (~/.npm) sin configuración de cache separada. Esto es más simple y recomendado sobre actions/cache manual para setups estándar. Para caching complejo (múltiples package managers, caches de workspace de monorepo), usa actions/cache directamente con claves custom y restore-keys para matching de fallback.

Límites de cache: GitHub provee 10GB de almacenamiento de cache por repositorio. Los caches se desalojan LRU (menos recientemente usado) cuando se alcanza el límite. Los caches específicos de rama se prefieren (el cache de una rama feature está disponible para su PR pero no para otras ramas) con fallback al cache de la rama por defecto. Usa restore-keys para definir patrones de fallback: un match parcial en el prefijo de la clave restaura el cache más reciente con ese prefijo, aunque la clave exacta no matchee.

Los artifacts son archivos producidos por un job y persistidos después de que se completa. Usa actions/upload-artifact@v7 para guardar outputs de build, reportes de test o datos de cobertura, y actions/download-artifact@v8 para recuperarlos en jobs posteriores. A diferencia del caching (que optimiza instalaciones repetidas de dependencias), los artifacts están diseñados para pasar outputs de build únicos entre jobs y hacerlos disponibles para descarga desde la UI del workflow run.

Patrones comunes de artifacts: un job de build sube binarios compilados, y un job de deploy los descarga. Un job de test sube reportes JUnit XML, y GitHub los renderiza en el resumen del workflow. Configura retention-days para controlar cuánto tiempo se almacenan los artifacts (por defecto 90 días, máximo 400). Para monorepos, usa nombres de artifact distintos por paquete para evitar colisiones cuando múltiples jobs de matrix suben simultáneamente.

Los artifacts tienen un límite de almacenamiento de 10GB por repositorio y un límite de 500MB por archivo subido. Para artifacts grandes, comprime antes de subir. En pipelines multi-job, los artifacts son el mecanismo principal para compartir estado: el job de test produce un artifact de reporte de cobertura, el job de build produce un artifact de digest de imagen Docker, y el job de deploy consume ambos para crear un deployment con cobertura de test verificada y el hash exacto de la imagen.

Los runners hosted por GitHub proveen ambientes Ubuntu, macOS y Windows con herramientas pre-instaladas. Son efímeros (destruidos después de cada job), seguros (VMs aisladas), y requieren cero mantenimiento. Sin embargo, tienen limitaciones: specs de hardware fijas (los runners Linux estándar son 2 CPU / 8GB RAM en repos privados, 4 CPU / 16GB RAM en repos públicos), customización de software limitada, y sin almacenamiento persistente entre jobs. Los self-hosted runners resuelven estas limitaciones.

Los self-hosted runners son máquinas que tú gestionas (físicas, VM o contenedor) que ejecutan jobs de GitHub Actions. Ventajas: hardware custom (GPU, ARM, alta memoria), caches persistentes, acceso a redes privadas (bases de datos, APIs internas), y sin facturación por minuto. Desventajas: tú gestionas seguridad (parchear el OS, aislar jobs), disponibilidad (mantener el runner online), y escalado (levantar más runners para la demanda). Usa actions-runner-controller en Kubernetes para auto-escalar self-hosted runners.

Para la mayoría de los proyectos, los runners hosted por GitHub son suficientes y recomendados por seguridad. Usa self-hosted runners solo cuando necesites hardware específico (GPU para entrenamiento ML, ARM para cross-compilación), acceso de red (desplegar a un cluster on-premise), o builds grandes que excedan los límites de memoria de los runners hosted estándar. Nunca uses self-hosted runners para repositorios públicos — cualquiera que pueda abrir un PR puede ejecutar código arbitrario en tu runner.

Los reusable workflows (trigger workflow_call) te permiten definir un workflow una vez y llamarlo desde otros workflows, similar a los templates compartidos de GitLab. El workflow llamado corre en el contexto del llamador, con inputs y secrets pasados explícitamente. Este es el mecanismo principal para estandarizar CI/CD entre repositorios en una organización GitHub.

Las composite actions agrupan múltiples steps en una sola action reutilizable con inputs y outputs definidos. A diferencia de los reusable workflows (que son archivos de workflow completos), las composite actions son steps que pueden mezclarse con otros steps en cualquier job. Son ideales para abstraer secuencias de steps repetitivas: "setup ambiente, autenticar, desplegar" se convierte en uses: ./.github/actions/deploy.

Workflow dispatch con inputs crea ejecuciones manuales parametrizadas: selecciona el ambiente, elige la versión, togglea feature flags — todo desde la UI de GitHub. Combinado con github.event.inputs, esto habilita deployments con un click, migraciones de base de datos y operaciones de mantenimiento. A escala, un workflow de deployment con inputs de ambiente y versión reemplaza scripts de deployment complejos con un solo click de botón.

Los workflows de GitHub Actions potencian el CI/CD de este sitio web (josenobile.co) y varios proyectos open-source y de clientes. Los workflows demuestran mejores prácticas para testing, building, despliegue de sitios estáticos, ejecución de reviews de código con AI, y mantenimiento de la salud del proyecto con jobs programados.

ARM64 Hosted Runners (GA): GitHub ahora ofrece runners hosted ARM64 gratuitos con las labels ubuntu-24.04-arm y ubuntu-22.04-arm para repositorios públicos. Los runners ARM entregan hasta 40% mejor rendimiento para workloads compatibles sin costo adicional. Esto es particularmente impactante para buildear imágenes Docker multi-arquitectura (amd64 + arm64 nativamente en vez de emulación QEMU), correr tests nativos ARM y reducir costos CI para organizaciones desplegando en infraestructura ARM (AWS Graviton, nodos GKE Arm). Usa runs-on: ubuntu-24.04-arm para optar.

Atestaciones de Artifacts: GitHub Actions ahora soporta atestaciones criptográficas de artifacts que vinculan artifacts de build a su código fuente y proceso de build. Cuando buildeas un binario, imagen de contenedor o cualquier artifact, la atestación prueba que fue buildeado desde un commit específico en tu repositorio por un workflow run específico. Esto provee seguridad de cadena de suministro haciendo verificable que los artifacts no fueron manipulados entre build y deployment. Las atestaciones siguen el framework in-toto e integran con estándares de procedencia SLSA.

Immutable Actions: Una feature de seguridad que asegura que las actions no fueron manipuladas entre publicación y consumo. Las immutable actions están firmadas criptográficamente y verificadas en runtime, previniendo ataques de cadena de suministro donde un actor malicioso modifica una action publicada. Combinado con atestaciones de artifacts, esto crea un pipeline verificado end-to-end donde tanto la configuración CI/CD (actions) como los outputs de build (artifacts) están verificados criptográficamente.

Runner Scale Set Client (Preview): Un módulo Go standalone para implementar autoscaling custom de self-hosted runners sin requerir Kubernetes. Antes, el autoscaling de runners requería el actions-runner-controller en Kubernetes. El nuevo Runner Scale Set Client provee la misma semántica de scale-set como librería Go, habilitando a los equipos a construir soluciones de autoscaling custom en cualquier infraestructura -- VMs, funciones serverless u orquestadores propietarios. Esto desacopla el autoscaling de runners de la dependencia de Kubernetes.

Controles de Runner para Copilot Agent (abril 2026): El agente de coding cloud de GitHub Copilot ahora corre sobre infraestructura de GitHub Actions, y las organizaciones pueden configurar un runner por defecto (incluyendo large runners o self-hosted runners) para el agente Copilot en todos los repositorios sin configuración por repo. La configuración de runners puede bloquearse a nivel de organización para prevenir sobrescrituras. Además, los runners hosted Windows ARM64 ahora están disponibles para GitHub Actions, trayendo soporte nativo de CI/CD para aplicaciones Windows Arm64 sin emulación. GitHub también redujo los precios de hosted-runners hasta un 39% efectivo enero 2026, haciendo CI/CD significativamente más accesible a escala.

Overrides de Service Containers, Claims Custom OIDC y Failover Azure (abril 2026): Los service containers en jobs de workflow ahora soportan overrides de entrypoint y command, habilitando scripts de inicialización y comandos de arranque personalizados para servicios sidecar como bases de datos y brokers de mensajes sin construir imágenes custom. Las propiedades custom de OIDC como claims es ahora GA -- las organizaciones pueden inyectar propiedades custom del repositorio en tokens OIDC, permitiendo a los proveedores cloud acotar permisos basados en equipo, ambiente o cualquier metadata personalizada. Azure private networking para hosted runners ahora incluye failover automático, manteniendo conectividad segura a VNETs de Azure incluso durante transiciones de infraestructura.