GitHub Actions: Lo Que Nadie Te Cuenta

Trabajo en GitHub. Uso Actions todos los días. También he depurado YAML a las 2am, he visto el visor de logs comerse mi navegador, y he hecho quince commits seguidos solo para descubrir por qué un condicional no estaba evaluando correctamente.

No vengo a decirte que Actions es perfecto. No lo es. El visor de logs ha hecho que ingenieros con experiencia cuestionen sus decisiones de vida. La sintaxis de expresiones YAML tiene una curva de aprendizaje que se siente más como un precipicio. El loop de push-esperar-fallar-repetir puede convertir un arreglo de cinco minutos en una tarde entera secuestrada.

Lo sé porque lo he vivido. Y he visto a miles de desarrolladores vivirlo también.

Pero esto también he visto: la mayoría del dolor viene de patrones que se pueden evitar. No todo. Parte es la plataforma poniéndose al día. Pero mucho tiene soluciones que existen hoy y que la gente todavía no ha descubierto porque el camino fácil es seguir copiando YAML y sufriendo.

Este artículo es lo que me hubiera gustado que alguien me dijera desde el primer día.

Deja de Usar el Visor de Logs

En serio. La interfaz web para leer logs de builds es la mayor fuente de frustración con Actions, y la solución más rápida es dejar de usarla.

gh run view --log-failed

Eso es todo. El paso que falló, en tu terminal, al instante. Sin hacer clic por tres páginas. Sin esperar a que el navegador decida si quiere renderizar hoy. Sin la ruleta del botón de atrás.

Si quieres el log completo:

gh run view --log

Si quieres ver un run en tiempo real:

gh run watch

El CLI es más rápido, puedes buscar con grep, y no se cae cuando tu suite de tests produce 50,000 líneas. Si en 2026 todavía estás haciendo clic por la interfaz web para leer logs, esta es tu señal para parar.

El Problema del YAML Es Real. Así Se Reduce.

Todo sistema de CI termina siendo “un montón de YAML.” Actions no es la excepción. Pero hay diferencia entre un workflow de 40 líneas que hace una cosa claramente y un monstruo de 400 líneas con condicionales anidados, matrices, y scripts de bash inline que harían llorar a un programador de shell.

El monstruo de 400 líneas pasa porque la gente no conoce las dos funcionalidades diseñadas para prevenirlo. O no las usa.

Workflows Reutilizables

Si tienes los mismos pasos de CI en múltiples repos, probablemente estás copiando y pegando workflows. Para.

# .github/workflows/ci.yml
jobs:
  build:
    uses: tu-org/.github/.github/workflows/build.yml@main  # @main está bien para repos internos que tú controlas
    with:
      node-version: '20'
    secrets: inherit

Un workflow, mantenido en un solo lugar, llamado desde todos lados. Cuando lo actualizas, cada repo que lo usa recibe la actualización. Sin desincronización. Sin “espera, ¿cuál repo tiene la última versión de nuestro script de deploy?”

Actions Compuestos

Los workflows reutilizables son para pipelines completos. Los actions compuestos son para pasos — los bloques de construcción.

# .github/actions/setup-project/action.yml
name: 'Setup Project'
runs:
  using: 'composite'
  steps:
    - uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6.3.0
      with:
        node-version: ${{ inputs.node-version }}
    - run: npm ci
      shell: bash
    - run: npm run build
      shell: bash

Ahora tus archivos de workflow se leen como oraciones, no como telenovelas:

steps:
  - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
  - uses: ./.github/actions/setup-project
    with:
      node-version: '20'
  - run: npm test

El YAML sigue ahí. Pero son 12 líneas, no 120. Y cuando el setup cambia, lo cambias en un solo lugar.

Rompe el Loop de Push-Esperar-Fallar

La parte más dolorosa de depurar Actions: haces un cambio de un carácter en un archivo de workflow, lo pusheas, esperas cuatro minutos a que un runner arranque, y descubres que te faltó una comilla. Quince commits después, tu historial de git parece un grito de auxilio.

act, una herramienta mantenida por la comunidad, ejecuta tus workflows localmente en contenedores Docker. Mismo ambiente, sin push.

act -j build

No es una réplica perfecta. Algunos contextos específicos de GitHub no existen localmente. Pero para “¿rompí el YAML?” y “¿mi script de bash funciona?”, corta ese loop de retroalimentación de minutos a segundos.

Para validación simple de sintaxis antes de ejecutar nada:

gh workflow view ci.yml

Si el YAML tiene problemas obvios, los detecta rápido. No es un linter completo, pero atrapa lo básico sin tener que pushear.

El Problema de Confianza del Marketplace (y Qué Hacer)

Cada uses: un-desconocido/action-cool@v2 es código que no escribiste ejecutándose con acceso a tu repo y tus secretos. Es una preocupación de seguridad real, y “solo pinea al SHA” es la respuesta correcta que nadie sigue.

Esto es lo que funciona en la práctica:

1. Pinea a SHAs y deja que Dependabot maneje las actualizaciones:

uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

Agrega la versión en un comentario para que los humanos puedan leerlo. Dependabot abrirá PRs cuando salgan nuevas versiones, y puedes revisar el diff antes de actualizar.

2. Usa actions mantenidos por GitHub cuando sea posible. actions/checkout, actions/setup-node, actions/cache — los mantiene el mismo equipo que construye la plataforma. Son auditados, probados y actualizados.

3. Para todo lo demás, lee el código fuente. Es open source. Si un action del marketplace es un script de 20 líneas metido en un Dockerfile, mejor copia las 20 líneas en un paso run: y asúmelo como tuyo.

4. Usa OpenSSF Scorecard para evaluar las prácticas del mantenedor antes de adoptar un action.

Lógica Condicional Sin Perder la Cabeza

La sintaxis de expresiones ${{ }} es una de esas cosas que es simple hasta que no lo es, y entonces es desconcertante. Los casos extremos con interpolación de strings, valores truthy y coerción de tipos le han mordido a todo el mundo al menos una vez.

Algunas reglas de supervivencia:

# Siempre pon comillas a las expresiones en `if:`
if: ${{ github.event_name == 'push' }}

# Usa fromJSON para booleanos de inputs
if: ${{ fromJSON(inputs.deploy) == true }}

# ¿Múltiples condiciones? Usa >- para unir las líneas.
if: >-
  ${{ github.ref == 'refs/heads/main' &&
      github.event_name == 'push' }}

Y si tu lógica condicional necesita un diagrama de flujo, eso es señal de que necesitas un workflow reutilizable con inputs, no más sentencias if:.

La función case() es una adición reciente que vale la pena conocer. Piensa en ella como un switch para expresiones. Reemplaza ternarios anidados que nadie puede leer.

Deja Que Copilot Escriba el YAML

No voy a pretender que escribir YAML es divertido. Pero en 2026, no tienes que escribir la mayoría.

En VS Code con GitHub Copilot, describe lo que quieres en un comentario:

# Deploy a producción en push a main, correr tests primero,
# cachear node_modules, notificar a Slack si falla

Copilot genera el workflow. Tú revisas y ajustas. Él maneja la sintaxis, los triggers on:, el runs-on:, el orden de los pasos, para que tú te enfoques en lo que el pipeline debe hacer, no en recordar si environment va dentro o fuera de jobs:.

Para workflows existentes, Copilot en modo agente puede refactorizar un archivo YAML de 400 líneas en workflows reutilizables y actions compuestos. Dile lo que quieres, revisa el PR.

Esto no arregla Actions. Te arregla a ti tener que pelear con él directamente.

Qué Está Mejorando Realmente

Dije que no iba a endulzar esto, así que voy a ser específica sobre qué ha mejorado y qué todavía necesita trabajo.

Mejor ahora:

• Job summaries, output estructurado en vez de solo líneas de log
• Runners más grandes, máquinas de 64 cores disponibles, runners ARM en GA
• Required workflows, enforcement a nivel de organización sin copiar y pegar
• Actions inmutables, actions publicados en GHCR con provenance
• case() y mejoras recientes en expresiones

Todavía necesita trabajo:

• El visor de logs. Ha mejorado, pero no está donde necesita estar para builds grandes. Usa el CLI.
• La experiencia de depuración. act ayuda, pero ejecución local de primera mano lo cambiaría todo.
• La curva de aprendizaje de las expresiones. El equipo de documentación ha mejorado esto constantemente, y se nota — pero todavía hay espacio para crecer.

No escribo esto para defender el honor de GitHub. Lo escribo porque he visto a demasiados equipos sufrir con problemas que tienen soluciones, y esas soluciones no están llegando a la gente lo suficientemente rápido.

Los fundamentos están ahí. La plataforma funciona. Pero “funciona” y “agradable” son cosas diferentes, y el espacio entre ellas es donde tu tarde desaparece. Estos patrones cierran esa brecha. No del todo. Pero lo suficiente.