Herramientas CI/CD

validador de GitHub Actionsformatea, valida y navega cada job

Pega un workflow YAML para formatearlo, recorrer el árbol job/step y previsualizar un borrador de matrix o cron antes de insertarlo.

Validación automática

YAML del workflow

Resultado

Todo se procesa en el navegador; nada se envía a GitHub ni a ningún servidor.

OpcionesSangría

Generador de matrix (borrador)

Variables

include (opcional)

exclude (opcional)

fail-fastmax-parallel (opcional)Insertar en el job

Genera una vista previa para ver el fragmento de strategy.matrix.

Generador de programación cron (borrador)

Expresión cron (5 campos)Zona horaria (opcional)

Genera una vista previa para ver el fragmento de on.schedule.

Esperando validación…

Un archivo workflow YAML de GitHub Actions casi siempre se rompe después de hacer push: un job sin runs-on, un valor de permissions que no existe en la enumeración real, o una programación que nunca se dispara en silencio. Este validador de GitHub Actions detecta ese tipo de error de forma local, antes de que arranque un run, revisando la estructura de la que la CI realmente depende, no solo una sintaxis YAML genérica.

Es útil cuando se edita a mano un workflow con varios jobs y hay que encontrar rápido el que falla, cuando se construye una matriz de compilación con varios sistemas operativos y versiones, cuando hay que ordenar referencias env, secrets y vars a lo largo de varios steps, o cuando se escribe una expresión cron en on.schedule y hace falta saber qué permite realmente GitHub Actions.

Por qué usar este validador de GitHub Actions

Un solo banco de trabajo en vez de saltar entre un linter YAML genérico, un generador de matrix y una herramienta de cron que no conoce GitHub Actions.

Formateo, validación de estructura y navegación job/step juntos

Al pegar un workflow se formatea el YAML, se revisan los id de job y step según la regla de nombres, se confirma que cada job declare runs-on o uses, se valida permissions contra su enumeración real (id-token solo acepta write o none) y se marcan filtros mutuamente excluyentes como branches y branches-ignore usados a la vez; luego se genera un árbol job/step en el que se puede hacer clic para saltar directo a la línea en el editor.

Ver reglas y límites

Workflow YAML de GitHub Actions formateado junto a un árbol de navegación job/step con un error de estructura resaltado

Ver exactamente dónde fallarán las referencias env, secrets y github

El panel de referencias lista cada expresión ${{ env.X }}, ${{ secrets.X }}, ${{ vars.X }} y ${{ github.X }} encontrada, junto con el job y el step al que pertenece, y marca los tres puntos de fallo documentados: env no se puede usar en el id ni en uses de un step, secrets no se puede leer directamente en una condición if:, y github no se puede usar dentro de uses:.

Ver cómo se extraen las referencias

Lista de referencias env, secrets, vars y github con tres entradas marcadas en los lugares donde GitHub Actions realmente rechaza la expresión

Un generador de cron que ya conoce los límites propios de GitHub Actions

El panel de cron construye una expresión estándar de cinco campos aplicando las restricciones que GitHub documenta para los disparadores schedule: intervalo mínimo de cinco minutos, UTC por defecto con zona horaria IANA opcional, sin alias como @daily, y la desactivación automática tras 60 días de inactividad en repositorios públicos.

Leer las preguntas sobre programación

Generador de cron que muestra el intervalo mínimo de cinco minutos, la zona UTC por defecto y un aviso de alias no soportado en GitHub Actions

Tres cosas fáciles de pasar por alto la primera vez

El banco de trabajo hace más cosas automáticamente de lo que muestra la barra de herramientas.

Pega un workflow o carga el ejemplo

Pega un workflow YAML copiado desde tu editor, o carga el ejemplo incluido: ya contiene un disparador schedule, un job con strategy.matrix y referencias env/secrets/github, así se ven las cinco funciones de una vez. La validación automática está activada por defecto y se vuelve a ejecutar 350ms después de dejar de escribir; nunca se sube nada.

Haz clic en cualquier nombre de job o step del árbol de navegación y el editor salta directo a esa línea; ahí es donde realmente se ahorra tiempo cuando un workflow tiene más de un par de jobs.

Trata los paneles de matrix y cron como borradores, no como cambios en vivo

Editar la tabla de variables de matrix o los campos de cron nunca toca el workflow por sí solo, solo genera una vista previa. Nada se escribe en strategy.matrix ni en on.schedule hasta hacer clic en Insertar, y hasta entonces el borrador se puede copiar por separado igualmente.

Escribe los números de versión entre comillas, como node-version: "3.10": sin comillas, YAML lee 3.10 como el número 3.1 y pierde el cero final sin avisar.
fail-fast viene en true por defecto y max-parallel queda vacío (sin límite), igual que los valores por defecto de GitHub Actions.

Lee las marcas de riesgo antes de confiar en un resultado sin errores

La lista de referencias env/secrets/vars/github marca justo los puntos donde GitHub Actions está documentado que falla, no una suposición de un linter genérico. Ctrl/Cmd+Enter vuelve a validar cuando la ejecución automática está apagada; si se sigue editando después de un resultado, copiar y descargar quedan deshabilitados hasta revalidar, para no exportar nunca un resultado desactualizado.

Un filtro sobre la lista de referencias permite ver solo env, secrets, vars o github a la vez, útil cuando un workflow tiene muchas expresiones.

Lo que realmente ocurre detrás

Cinco funciones que trabajan juntas en vez de cinco pestañas separadas.

Formateo de YAML con la indentación que elijas

Reformatea un workflow con una indentación consistente de dos o cuatro espacios, para que el diff de un pull request muestre solo las líneas que realmente cambiaron, no un archivo entero reordenado.

Comprobaciones estructurales contra las reglas reales del workflow

Los id de job y step se comprueban contra el patrón de nombres requerido, cada job se confirma con runs-on o uses, los valores de permissions se comparan con su enumeración real, y los filtros mutuamente excluyentes como branches y branches-ignore se marcan cuando aparecen juntos en el mismo disparador.

Árbol de navegación job/step con clic

El árbol refleja la estructura real de jobs y steps del workflow; al seleccionar una entrada, el editor se desplaza exactamente a esa línea, sin tener que contar niveles de indentación a mano.

Generador de matrix con include, exclude y fail-fast

Arma una tabla de variables del estilo os/versión, agrega combinaciones include o exclude, ajusta fail-fast y max-parallel, previsualiza el strategy.matrix resultante e insértalo en el job elegido.

Inventario de referencias env/secrets/vars/github

Cada expresión ${{ }} que referencia env, secrets, vars o github se extrae y se lista por job y step, con un filtro para aislar un solo contexto a la vez.

Generador de fragmentos cron pensado para GitHub Actions

Arma una programación de cinco campos a partir de preajustes habituales o una expresión personalizada, previsualiza la entrada exacta de on.schedule e insértala; los límites de programación propios de GitHub se aplican automáticamente, sin tener que recordarlos.

Qué revisa esta herramienta, y qué deja fuera a propósito

Conocer los límites importa más que una lista larga de funciones.

Nada se conecta a GitHub: Este validador de GitHub Actions solo lee YAML de forma local. Nunca llama a la API de GitHub, nunca hace fork ni push de un repositorio, y nunca dispara ni ejecuta un workflow: solo formatea y revisa el texto pegado, todo en el propio dispositivo.
Las expresiones no se evalúan: ${{ github.sha }} o ${{ steps.build.outputs.version }} se extraen y se listan, pero no se resuelven a un valor real de ejecución. Probar el comportamiento real de las expresiones necesita un motor dedicado, que es una herramienta aparte; esta no lo simula con un eval de JavaScript a propósito.
La validación de schema es un subconjunto acotado, no actionlint: La validación estructural cubre la parte del schema público de schemastore.org que no depende de metadatos externos: id de job/step, runs-on/uses, permissions, conflictos de filtros. No revisa los tipos de entrada de una action, las versiones de actions del Marketplace ni una lista actualizada de etiquetas de runner soportadas, porque esos metadatos quedan obsoletos en cuanto se guardan en caché sin conexión.
Sin grafo de dependencias: El árbol job/step muestra estructura, no un DAG con las relaciones needs: entre jobs. Para ver ese grafo de dependencias hace falta otro tipo de vista, que esta herramienta todavía no ofrece.
Los límites de programación están documentados, pero no garantizados: El generador de cron aplica las reglas publicadas por GitHub: mínimo de cinco minutos, UTC por defecto, sin alias como @daily; pero no puede garantizar que el campo timezone opcional se respete, ni que una programación se dispare exactamente al minuto indicado; GitHub mismo señala retrasos posibles con carga alta y la desactivación automática tras 60 días de inactividad del repositorio.

Preguntas frecuentes sobre el validador de GitHub Actions

Respuestas basadas en lo que documenta GitHub, no en suposiciones.

¿La función de timezone en una programación cron de GitHub Actions realmente funciona?

Lo que se genera es sintácticamente correcto: GitHub añadió soporte opcional de zona horaria IANA a schedule en 2024. Pero las propias discusiones de la comunidad de GitHub incluyen reportes reales de que no se respetó. Este validador solo garantiza que el fragmento coincide con la sintaxis publicada, no que el programador de GitHub la aplique de verdad.

¿Por qué mi programación cron de GitHub Actions no se ejecuta a la hora que configuré?

Hay unas cuantas causas reales: el archivo workflow no está en la rama por defecto, el repositorio estuvo inactivo y GitHub desactivó la programación automáticamente tras 60 días, o la expresión usa un intervalo menor al mínimo documentado de cinco minutos. GitHub también señala que las ejecuciones programadas pueden retrasarse en momentos de mucha carga, sobre todo cerca de las horas en punto; esta herramienta valida la sintaxis cron, pero no puede garantizar la hora exacta de disparo.

GitHub solo dice "you have an error in your yaml syntax" sin decir en qué línea, ¿cómo encontrarla?

Pega el workflow en este validador de GitHub Actions: indica el nombre exacto del job o step junto con la línea y la columna, en lugar del mensaje genérico de GitHub. La validación automática se repite 350ms después de dejar de escribir, así que la ubicación marcada se actualiza mientras se corrige.

¿Por qué el bloque with: de un reusable workflow muestra "Unrecognized named-value: 'env'"?

Porque el contexto env simplemente no está disponible dentro de with:, una de las tres restricciones documentadas que el panel de referencias marca directamente (env tampoco se permite en el id ni en uses de un step). Hay que mover el valor a un env a nivel de job o de workflow, o pasarlo explícitamente como input al reusable workflow.

¿Cómo usar un secret de GitHub Actions dentro de una condición if?

No de forma directa: secrets no se puede leer dentro de una condición if:. Primero hay que asignar el secret a una variable env a nivel de job o de step, y luego comprobar ese valor de env en la condición if:. Es uno de los tres puntos de riesgo que el panel de referencias resalta para cada referencia secrets.*.

¿Por qué el número de versión matrix 3.10 se convierte en 3.1?

YAML lee un 3.10 sin comillas como el número 3.1 y pierde el cero final en silencio; es una particularidad del análisis de YAML, no un fallo de GitHub Actions. El generador de matrix detecta valores con forma de versión y les pone comillas automáticamente al insertar el strategy.matrix generado.

¿Encontraste un workflow que esta herramienta juzga mal?

Prueba este validador de GitHub Actions ahora

Pega un workflow en este validador de GitHub Actions, mira cómo se actualizan el árbol job/step y la lista de referencias, y prepara un borrador de matrix o cron cuando lo necesites.

Todo se queda en el navegador: no se sube nada, y ningún workflow se dispara jamás.

Volver a la herramienta Ver herramientas CI/CD

Todo el análisis ocurre localmente en tu navegador.

validador de GitHub Actionsformatea, valida y navega cada job