Acerca de esta herramienta
La mayoría de las suites de test necesitan el mismo esqueleto de CI: obtener el código, instalar un runtime, instalar dependencias y navegadores, ejecutar los tests y conservar el informe cuando algo falla. Este generador escribe ese workflow para Playwright (TypeScript), Cypress, Selenium con Java y Maven, o pytest, usando las versiones mayores actuales de las acciones oficiales (checkout@v4, setup-node@v4, setup-java@v4, setup-python@v5, cache@v4, upload-artifact@v4). Para Playwright puede repartir la suite en jobs paralelos con --shard=i/n y después fusionar los blob reports en un único informe HTML, siguiendo el patrón documentado por Playwright. Las ejecuciones programadas usan cron de 5 campos en UTC, como exige GitHub Actions.
Cómo usarla
- Elige tu framework y la versión del runtime, y después los triggers: push, pull_request, una programación cron o workflow_dispatch manual.
- Selecciona los navegadores y, para Playwright, el número de shards. Mantén activadas la caché y la subida de informes salvo que tengas un motivo para no hacerlo.
- Copia o descarga el YAML, guárdalo en .github/workflows/ de tu repositorio y comprueba que comandos como npm ci o pip install -r requirements.txt coinciden con tu proyecto.
Preguntas frecuentes: Generador de workflows de GitHub Actions para tests
¿Por qué la programación se ejecuta a una hora distinta de la esperada?
GitHub Actions evalúa cron en UTC, así que convierte desde tu zona horaria local. Las ejecuciones programadas también pueden empezar tarde en periodos de mucha carga, y en los repositorios públicos los workflows programados se desactivan automáticamente tras 60 días sin actividad en el repositorio.
¿Cómo funciona aquí el sharding de Playwright?
Una matriz lanza un job por shard y cada uno ejecuta npx playwright test --shard=i/n con el reporter blob. Un job posterior descarga todos los blob reports y ejecuta npx playwright merge-reports para producir un único artefacto con el informe HTML.
¿Dónde pongo credenciales como la contraseña de un usuario de prueba?
Guárdalas como secretos del repositorio o del entorno y referéncialas con ${{ secrets.NAME }} en un bloque env. Nunca las incluyas en el archivo del workflow.