Aplicar buenas prácticas en GitHub Actions marca la diferencia entre un workflow estable y uno que rompe tu pipeline o infla tu factura. Si ya entendiste los conceptos básicos de jobs, runners y actions, ahora te toca aprender cómo escribir workflows mantenibles, seguros y económicos para tus proyectos.

¿Por qué conviene usar workflows pequeños en GitHub Actions?

Un workflow gigante que haga todo en un solo archivo se ve cómodo al principio, pero se convierte en un dolor de cabeza cuando algo falla. La recomendación es dividir.

En lugar de un solo workflow para todo el ciclo, crea uno por responsabilidad: uno para continuous integration, otro para continuous deployment, y archivos separados para cada automatización del proyecto, como manejo de issues, pull requests o releases.

Esta separación te da tres beneficios concretos:

• Mayor modularización del código de automatización.
• Debug más rápido cuando algo falla, porque sabes exactamente qué archivo revisar.
• Logs más cortos y fáciles de leer.

¿Cuántos jobs debe tener un workflow? Los necesarios para una sola responsabilidad. Si tu workflow mezcla deploy, tests y notificaciones, es momento de partirlo en archivos distintos.

¿Cómo evitar que un job consuma minutos infinitos con timeouts?

GitHub cobra los runners de Actions en repositorios privados por minutos de ejecución. Si un paso entra en bucle infinito o se queda colgado esperando una respuesta, tu factura crece sin que tú lo notes.

Por eso debes configurar el parámetro timeout-minutes dentro de cada job. Por ejemplo, un job llamado config-lead puede llevar un timeout de 30 minutos, suficiente para terminar bajo condiciones normales y un corte automático si algo se rompe.

yaml jobs: config-lead: runs-on: ubuntu-latest timeout-minutes: 30 steps: - uses: actions/checkout@v3

Este pequeño ajuste te protege de facturas infladas y de pipelines zombi que nunca terminan.

¿Es seguro usar actions de terceros desde el marketplace?

El marketplace de GitHub Actions tiene más de 17.000 actions creadas por la comunidad. Es uno de los grandes atractivos de la plataforma, pero también una puerta de entrada para problemas si no eliges con criterio.

Piensa en cada action de terceros como una dependencia más de tu proyecto, igual que una librería de npm o un framework. Antes de adoptarla revisa:

• Que el autor sea conocido o tenga reputación visible.
• Que el repositorio tenga actividad reciente y no esté abandonado hace años.
• Que respondan issues y publiquen correcciones cuando aparecen vulnerabilidades.

Una action sin mantenimiento es una bomba de tiempo: si aparece un fallo de seguridad, nadie lo va a arreglar por ti.

¿Por qué fijar la versión de un action con SHA en vez de tag?

Lo común es escribir actions/checkout@v3, apuntando a la última versión estable. Funciona en la mayoría de casos, pero tiene un riesgo: el autor puede mover ese tag v3 a un nuevo commit que rompa algo o que incluya código malicioso.

Para jobs sensibles, como un deploy a producción usando una action de un tercero, conviene anclar el SHA exacto del commit que ya probaste:

yaml steps:

• uses: some-author/deploy-action@a1b2c3d4e5f6...

Así, aunque el autor publique cambios bajo el mismo tag, tu workflow seguirá ejecutando exactamente la versión que validaste.

¿Qué es el SHA de un commit? Es el hash único que GitHub genera para identificar un commit específico. Usarlo te garantiza que ejecutas siempre el mismo código, sin sorpresas.

¿Cómo limitar los permisos del GITHUB_TOKEN en tus workflows?

Muchas actions reciben acceso al repositorio mediante github.token, un token que GitHub genera automáticamente. Por defecto trae permisos amplios, y ese es justamente el problema.

La buena práctica es aplicar el principio de mínimo privilegio: dale solo lectura, y si una tarea concreta necesita escritura, súbele el permiso únicamente para ese caso.

yaml permissions: contents: read issues: write

Si una action que usas se ve comprometida por un atacante, unos permisos restringidos limitan el daño que puede hacer en tu repositorio. Es la diferencia entre un susto y una crisis.

Buenas prácticas resumidas para tus workflows de GitHub Actions

Estas son las cinco prácticas que conviene aplicar desde el primer workflow que escribas:

1. Mantén workflows pequeños y enfocados en una sola responsabilidad.
2. Configura timeout-minutes en cada job para controlar costos.
3. Evalúa la reputación y mantenimiento de las actions de terceros antes de usarlas.
4. Especifica versiones con tag o, mejor, con SHA en jobs críticos.
5. Limita los permisos del token al mínimo necesario.

Cuéntame en los comentarios cuál de estas prácticas vas a aplicar primero en tus repositorios y qué otras has descubierto trabajando con GitHub Actions.