GitHub Actions es hoy el CI/CD más usado en proyectos open source y en muchas empresas. Este generador crea workflows YAML válidos para los stacks más comunes (Node, Python, Docker, Deploy) con triggers, jobs, matrix builds y caches ya configurados, evitando los errores de indentación típicos al escribir YAML a mano.
Anatomía de un workflow
Un workflow vive en `.github/workflows/*.yml`. Contiene `on:` (qué eventos lo disparan), `jobs:` (unidades paralelas), y dentro de cada job una lista de `steps`. Cada step ejecuta un `run:` (comando shell) o un `uses:` (una action publicada). El runner (`runs-on: ubuntu-latest`) provisiona una VM limpia por job.
Cache y matrix: los dos aceleradores clave
Sin cache, cada CI reinstala todo el árbol de dependencias. `actions/cache` o el cache integrado en `actions/setup-node` reducen build times de 5 minutos a 30 segundos. La estrategia `matrix` permite ejecutar el mismo job en varias versiones (Node 18/20/22, OS ubuntu/macos/windows) sin duplicar YAML.
Secrets y permissions mínimos
Guarda credenciales en Settings → Secrets, nunca en el YAML. Restringe permisos con `permissions:` a nivel de workflow o job: por defecto GitHub concede `contents: write` al `GITHUB_TOKEN`, que es demasiado. Para deploy a cloud, prefiere OIDC (federated credentials) frente a claves de larga duración.
Casos de uso comunes
- Ejecutar tests en cada pull request.
- Publicar paquetes a npm/PyPI en cada tag.
- Construir y empujar imágenes Docker a GHCR o Docker Hub.
Buenas prácticas
- Pinea las actions por SHA (`uses: actions/checkout@a1b2c3d`) en workflows sensibles.
- Usa `concurrency:` para cancelar builds obsoletos y ahorrar minutos.
- Divide en jobs paralelos cuando compilación y tests son independientes.