⚙️ Generador de GitHub Actions

Selecciona tipo de flujo y disparadores y obten YAML listo para .github/workflows/. Soporta Node.js, Python, PHP, Go, Docker, Pages, Vercel, Netlify, Release, Cron y Lint.

100% Gratis Sin registro Solo navegador 5 idiomas Modo oscuro

🔒 Sobre la privacidad

・El YAML se genera completamente en tu navegador
・Tus datos de entrada nunca se envian a ningun servidor
・Sin registros, sin base de datos
・Sin registro, sin inicio de sesión, sin pago

Tipo de flujo

Nombre (.github/workflows/)

Disparadores

push pull_request schedule workflow_dispatch

Rama

Expresion cron

YAML generado

(pulsa Generar YAML arriba)

📖 Dónde se suele tropezar

Elige un tipo de flujo de trabajo (Node, Python, PHP, Go, Docker, Pages, Vercel, Netlify, Release, Cron o Lint) y sus disparadores, y se genera un YAML que puedes dejar directamente en .github/workflows/. Todo se ejecuta en el navegador y los nombres de rama y versiones no se transmiten. Lo que se genera es un flujo sintacticamente valido, no un flujo que vaya a pasar en tu proyecto: los comandos reales para instalar dependencias y ejecutar pruebas cambian de un repositorio a otro. Y lo que de verdad duele en CI no es el formato del YAML, sino los permisos y el tiempo. De eso trata lo que sigue.

Caso	Qué ocurre	Qué hacer
Un pull request desde una bifurcacion no recibe secretos	Un flujo disparado por `pull_request` se ejecuta con un `GITHUB_TOKEN` de solo lectura y no recibe ninguno de los secretos del repositorio cuando el pull request viene de una bifurcacion. Es una medida de seguridad deliberada: de lo contrario, cualquiera podria hacer que tus secretos se imprimieran con solo abrir un pull request. La consecuencia es que un flujo que contenga un despliegue o una subida de cobertura siempre falla en los pull requests desde bifurcaciones. Existe un rodeo peligroso muy conocido: cambiar a `pull_request_target` si entrega los secretos, pero ese disparador se ejecuta con los permisos de la rama base, de modo que descargar y ejecutar alli el codigo del pull request hace correr codigo escrito por alguien de fuera con tus secretos en la mano: en la practica, una toma de control del repositorio.	Divide el flujo en dos. Ejecuta las pruebas y el lint en `pull_request`, que no necesita secretos, y los despliegues en `push` a main o en `release`. Asi los pull requests de bifurcaciones pasan CI con normalidad y no existe via alguna por la que los secretos puedan salir. Si usas `pull_request_target`, no descargues nunca el codigo del pull request: limitalo a cosas que no ejecutan codigo, como etiquetar o publicar un comentario. Ademas, declara `permissions:` de forma explicita al principio de cada flujo: escribir solo `permissions: {contents: read}` ya retira el permiso de escritura del `GITHUB_TOKEN` de ese flujo. Devolver despues unicamente los permisos que cada trabajo necesita es el orden correcto.
Referenciar una accion de terceros por etiqueta	El `v1` de `uses: some/action@v1` es una rama o etiqueta, es decir, una referencia movil: si el autor de la accion, o quien se apodere de esa cuenta, cambia su contenido, tu CI ejecutara codigo distinto en la siguiente pasada. Ese codigo tiene acceso al `GITHUB_TOKEN` y a cualquier secreto que hayas pasado al trabajo. No es un supuesto teorico: acciones populares han sido comprometidas de verdad y usadas para recolectar secretos. *Las oficiales `actions/` son una cosa, pero referenciar a la ligera una accioncita util en `@main` no se diferencia mucho de dar a alguien acceso de escritura a tu repositorio.**	Fija las acciones de terceros a un SHA de commit: `uses: some/action@a1b2c3d4...`. Un SHA no se puede reescribir, de modo que lo que se ejecutara queda determinado. Deja las actualizaciones en manos de Dependabot: anadir `package-ecosystem: "github-actions"` a `.github/dependabot.yml` hace que abra pull requests que suben el SHA; fijar y actualizar no estan renidos. Reducir el numero de acciones tambien ayuda: si una accion solo copia un archivo, escribir `cp` bajo `run:` elimina una dependencia. Y pasa los secretos a los trabajos de la forma mas estrecha posible: ponlos como variables de entorno a nivel de flujo y todas las acciones de dentro podran leerlos.
El cron no corre puntual y se detiene a los 60 dias	El disparador `schedule` tiene tres trampas mas alla de su sintaxis. Las horas son siempre UTC, no tu zona horaria: *`0 3 * ` significa las tres de la madrugada UTC. Las ejecuciones no son puntuales: en momentos de mucha carga se retrasan de minutos a decenas de minutos y una ejecucion puede omitirse por completo. La hora en punto es la franja mas concurrida, asi que basta con evitar las horas redondas para ganar estabilidad. La tercera es la que mas sorprende: GitHub desactiva automaticamente los flujos programados en un repositorio sin commits durante 60 dias: se envia un correo, pero si se te pasa, descubrir meses despues que no se ha ejecutado nada es un desenlace de lo mas corriente*.	Escribe la expresion cron en UTC y desplazala unos minutos respecto de la hora redonda: `17 3 * * ` en lugar de `0 3 * `. Y anade siempre `workflow_dispatch` junto a ella: poder dispararlo a mano es lo que te permite probarlo y relanzarlo* (un flujo que no puedes probar sin esperar a la programacion es en si mismo una fuente de accidentes). La defensa frente a la desactivacion automatica es poder darte cuenta: haz que el trabajo notifique el exito a un sistema externo, de forma que la ausencia de notificacion sea detectable; alertar solo de los fallos no permite detectar un trabajo que dejo de ejecutarse. Si necesitas horarios exactos o alta fiabilidad, usa un planificador dedicado en lugar del cron de GitHub Actions.

Construye las claves de cache junto con el archivo de bloqueo. Si el cache: npm de actions/setup-node o la key de actions/cache no incluye un hash del archivo de bloqueo, se seguira restaurando una cache antigua aunque actualices las dependencias, lo que produce la situacion opaca de que en local esta arreglado y solo CI falla, con dependencias caducas. Mete hashFiles('**/package-lock.json') en la clave. Las caches ademas se comparten entre ramas: una cache envenenada contagia a las demas ramas, asi que ante la duda cambia el nombre de la clave y reconstruyela. Una cosa mas: cuida de no imprimir secretos en el registro. GitHub enmascara automaticamente los secretos registrados, pero un valor transformado (codificado en Base64, incrustado en JSON o recortado en parte) no se enmascara. Activar set -x o la salida de depuracion registra la linea de comandos completa, y en un repositorio publico cualquiera puede leer el registro de Actions.

📖 Cómo usar

1

Elige el tipo

Elige Node.js, Python, PHP, Go, Docker, Pages, etc.
2

Configura disparadores y rama

Activa push, pull_request, schedule o ejecucion manual.
3

Genera el YAML y haz commit

Pulsa Generar YAML, copia o descarga, coloca el archivo en .github/workflows/ y haz push.

❓ Preguntas frecuentes

¿Como configuro los secrets?

Anade el secret en Settings → Secrets and variables → Actions con el mismo nombre.

¿Que versiones de actions usa?

Usa actions/checkout@v4 y actions/setup-* v5 estables.

¿Funciona con runners auto-hospedados?

Si. Cambia runs-on a self-hosted en el YAML generado.

🔗 Herramientas relacionadas

🐛 ¿Encontró un problema con esta herramienta?

Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.