Lintador y formateador de YAML de GitHub Actions
Guía
Lintador y formateador de YAML de GitHub Actions
Pega un archivo de flujo de trabajo de GitHub Actions en la caja de entrada o haz clic en uno de los enlaces de ejemplo para cargar un ejemplo de CI, liberación o sintaxis obsoleta. El analizador valida tu flujo de trabajo contra un esquema integrado para desencadenadores, trabajos, pasos, ejecutores, permisos y llamadas reutilizables, y luego reformata el YAML con un orden de claves consciente del flujo de trabajo para que todos los archivos en tu repositorio tengan el mismo aspecto.
Cómo Usar
- Pega tu
.github/workflows/*.ymlColoca el archivo en la caja de entrada, o haz clic en uno de los enlaces de ejemplo para cargar un ejemplo de CI, liberación o sintaxis obsoleta. - Palanca Ordenar Claves para reordenar campos usando el orden convencional de GitHub Actions (nombre, on, permisos, trabajos, luego runs-on, needs, pasos).
- Mantener Validar contra esquema de GitHub Actions activado para detectar campos obligatorios faltantes, tipos de eventos desconocidos, etiquetas de ejecutor inválidas y estructuras rotas
needsreferencias. - Mantener Mostrar sugerencias de mejores prácticas activado para sugerencias de cadena de suministro y fiabilidad (fijar acciones de terceros a una SHA, añadir
timeout-minutes, reemplazar comandos obsoletos del flujo de trabajo). - Copiar el YAML formateado o descargarlo como un
.ymlarchivo listo para commit.
Características
- Validación de esquema – Campos obligatorios de nivel superior (
on,jobs), nombres permitidos de eventos de desencadenamiento, claves válidas para trabajos y pasos, y alcances correctos de permisos. - Reglas para trabajos reutilizables – Detecta cuando un trabajo mezcla
usesconruns-onosteps, lo que rechaza GitHub en tiempo de ejecución. - Verificación del grafo de necesidades – Detecta referencias a sí mismo y dependencias de trabajos que no existen en el archivo.
- Analizador de referencias de acciones – Detecta valores que faltan
uses:o que no están en@refforma.owner/repoDetección de sintaxis obsoleta - – Advertencia sobre entornos con la sustitución moderna.
::set-env,::set-output,::save-stateynode12/node16Sugerencias de mejores prácticas - – Sugerencia de fijar acciones de terceros a una SHA de commit y añadir para evitar trabajos que se expandan indefinidamente.
timeout-minutesVerificación de cron - – Valida que las entradas de cron tengan exactamente cinco campos. Formateador consciente del flujo de trabajo
on.schedule– Reordena las claves de nivel superior, nivel de trabajo y nivel de paso en el orden convencional de GitHub Actions para diferencias consistentes. - – Ningún contenido del flujo de trabajo se envía a un servidor. ¿Por qué los flujos de trabajo de GitHub Actions son tan propensos a errores estructurales?
- Funciona completamente en tu navegador El YAML del flujo de trabajo sigue un esquema estricto con claves obligatorias de nivel superior, nombres fijos de eventos de desencadenamiento y reglas de claves por trabajo que cambian según si el trabajo es un trabajo normal o una llamada a un flujo de trabajo reutilizable. El archivo solo se analiza cuando se desencadena un evento en GitHub, por lo que un error de escritura en el nombre de una clave o un evento desconocido permanece silenciosamente en el repositorio hasta que el siguiente push o PR falle. La validación basada en esquema detecta estos tipos de errores antes de que lleguen al ejecutor.
Preguntas frecuentes
-
¿Qué protege realmente fijar una acción a una SHA de commit?
GitHub Actions resuelve
-
a la versión de commit que el
etiqueta apunta en tiempo de ejecución. Como las etiquetas son mutables, un mantenedor (o un atacante que compromete la cuenta del mantenedor) puede mover
uses: owner/action@v1a un commit malicioso y cada flujo de trabajo que dependa de él ejecutará el nuevo código en la próxima ejecución. Fijar a una SHA de 40 caracteres completa congela el código fuente de la acción en una revisión conocida, por lo que un cambio futuro en la etiqueta no puede sustituir silenciosamente el comportamiento diferente.v1¿Por qué se desactivaron los comandos ::set-env, ::set-output y ::save-state?v1Estos comandos de flujo de trabajo escribían variables de entorno, salidas de paso y estado guardado emitiendo líneas especialmente formateadas en stdout. Cualquier herramienta que ejecutara el ejecutor podría imprimir el mismo formato y inyectar valores arbitrarios en -
o salidas de paso, incluyendo sobrescribir
o secretos que dependía el paso siguiente. Las sustituciones utilizan archivos dedicados y de solo escritura (
GITHUB_ENV) que los subprocesos no pueden leer ni modificar después de que se haya completado.PATH¿Por qué el analizador pide un valor de tiempo de espera en minutos para cada trabajo?$GITHUB_ENV,$GITHUB_OUTPUT,$GITHUB_STATESin -
, un trabajo ejecutado en GitHub puede ejecutarse hasta 360 minutos (seis horas) antes de que la plataforma lo cancele. Un proceso atascado, una espera mal configurada o una prueba que se expanda puede consumir todo el tiempo disponible, bloqueando la cola y quemando minutos de tu plan. Establecer un límite superior explícito en cada trabajo convierte ese peor caso en un fallo rápido que revela inmediatamente el error.
Pega el contenido de tu .github/workflows/*.yml aquí
timeout-minutesDescargar como .yml
Instalar extensiones
Agregue herramientas IO a su navegador favorito para obtener acceso instantáneo y búsquedas más rápidas
恵 ¡El marcador ha llegado!
Marcador es una forma divertida de llevar un registro de tus juegos, todos los datos se almacenan en tu navegador. ¡Próximamente habrá más funciones!
Herramientas clave
Ver todo Los recién llegados
Ver todoActualizar: Nuestro última herramienta se agregó el 7 de junio de 2026
