Depura un error de sangría YAML convirtiéndolo a JSON

El paso que nunca se ejecutó: un archivo de flujo de trabajo que se analizó bien y una clave que terminó en un nivel demasiado alto

Un flujo de trabajo se puede analizar correctamente colocando `with` al lado de un paso en lugar de dentro de él. Luego, el corredor ignora o rechaza la forma más tarde, y la inspección visual pasa por alto el cambio porque la fuente permanece ordenada. La conversión a JSON expone el padre real a través de llaves y límites de matriz.

ToolAcre informa YAML mal formado con línea y columna, pero una estructura incorrecta válida no produce ningún error de sintaxis. Por lo tanto, el árbol convertido es una vista de diagnóstico: le indica lo que aceptó este analizador, no lo que pretendía el esquema de flujo de trabajo.

Por qué los errores de sangría a menudo no son errores: la estructura de YAML son espacios en blanco, por lo que una línea desplazada generalmente crea un documento válido pero diferente

El espacio en blanco lleva la jerarquía YAML. Mover una línea hacia la izquierda puede convertir a un niño en hermano; mover un guión puede colocar un elemento en otra secuencia. Ambos documentos pueden satisfacer la gramática YAML. La validación de sintaxis no puede decidir qué anidamiento coincide con la aplicación.

Las pestañas con sangría son rechazadas por el analizador y reciben una posición. Los espacios que producen una jerarquía válida incorrecta requieren en su lugar una comparación estructural. Esa diferencia explica por qué algunos errores de sangría fallan inmediatamente mientras que otros sobreviven hasta el comportamiento de la aplicación.

Lo que JSON hace explícito: llaves y corchetes que muestran con precisión a qué objeto pertenece una clave

JSON escribe límites de objetos con llaves y miembros de la matriz con corchetes. Aparece una clave YAML fuera del objeto donde la esperaba y un guión se convierte en un límite de matriz difícil de pasar por alto. La sangría en bonito JSON es presentación; la puntuación define la estructura.

La vista también revela los tipos resueltos. Un escalar sin comillas puede ser nulo, numérico o booleano según el esquema seleccionado. Corregir la jerarquía sin verificar los valores puede dejar un segundo error, así que compare tanto la ruta de la propiedad como el tipo JSON.

Formas comunes del error: un elemento de lista bajo el padre equivocado, una clave que se convirtió en hermana en lugar de hija y tabulaciones mezcladas con espacios.

Los errores comunes incluyen un elemento de secuencia alineado con la lista incorrecta, una clave de asignación con sangría en un hermano y caracteres de tabulación mezclados con espacios. Las claves duplicadas son otra trampa: ToolAcre mantiene el último valor y advierte con una posición, por lo que JSON contiene solo la propiedad superviviente.

Los anclajes pueden hacer que el resultado parezca más grande porque los alias se expanden en datos repetidos. Esto es lo que se espera de esta conversión y no debe confundirse con una sangría accidental. Lea las advertencias antes de atribuir cada diferencia estructural a los espacios en blanco.

Ejemplo resuelto: un flujo de trabajo de CI con un bloque 'con' mal sangrado: conversión a JSON, detección de la clave mal colocada, corrección y reconversión

Cree un trabajo redactado con `steps`, una entrada `uses` y una asignación `with`. Quite la sangría a `with` para que se convierta en hermano de `steps` y luego convierta. Las llaves JSON muestran que `with` pertenece al trabajo en lugar del objeto de paso. Muévalo debajo del elemento de la lista y reconviértalo para ver el anidamiento previsto.

Este ejemplo evita afirmar cómo responde un servicio de CI específico, porque el convertidor no carga ese esquema. La prueba es la jerarquía analizada. La validación del esquema debe seguir y luego puede informar si `with` se acepta en la ruta corregida.

Usando la conversión inversa: JSON a YAML para producir una versión con sangría correcta que puedes volver a pegar

Una vez que la estructura JSON es correcta, convertirla nuevamente a YAML produce una sangría consistente en el serializador. Las cadenas ambiguas pueden aparecer entre comillas y los comentarios no se restauran. Trate la salida como una serialización de datos limpia, no como un formateador que preserva el origen.

Si los comentarios originales explican opciones operativas, copie la estructura corregida en el archivo mantenido en lugar de reemplazarla a ciegas. Un archivo generado puede ser estructuralmente correcto y editorialmente incompleto.

Lo que esto no cubre: validación semántica frente al flujo de trabajo o esquema de manifiesto, que detecta claves desconocidas en lugar de claves fuera de lugar.

No está involucrado ningún flujo de trabajo, Compose, Kubernetes o esquema de aplicación. Una clave puede estar debajo del padre previsto y aun así estar mal escrita o no ser compatible. Los convertidores de sintaxis solo prueban que YAML se acepta y muestran el valor resultante en forma de JSON.

Utilice el validador de la plataforma propietaria para claves desconocidas, campos obligatorios y restricciones semánticas. Mantener separadas las comprobaciones de sintaxis y esquema produce fallas más claras y evita acreditar a un convertidor genérico un conocimiento de dominio que no tiene.

Conclusión: cuando YAML se ve bien y se comporta mal, mírelo como JSON y cómo el panel de convertidores de sintaxis lo hace instantáneamente

Cuando YAML parece correcto pero se comporta mal, inspeccione el árbol analizado. JSON llaves y corchetes hacen explícito el parentesco, mientras que las advertencias de ToolAcre exponen duplicados, secuencias y cambios de valores que pueden complicar el panorama.

Corrija un error de jerarquía, reconvierta y luego ejecute la validación del esquema. Esta secuencia convierte una sospecha de espacio en blanco invisible en una estructura observable sin afirmar que una conversión exitosa haga que la configuración sea válida para su destino.

Al comparar el antes y el después, céntrese en las rutas de propiedad en lugar de en los números de línea porque la serialización puede reordenar la presentación o agregar comillas. Una revisión útil enumera la ruta esperada, su tipo JSON y si se encuentra dentro de un objeto o matriz. Esa pequeña lista de verificación detecta una segunda clave mal colocada incluso cuando se soluciona el primer síntoma visual, y evita convertir el formato YAML generado en el oráculo de prueba.