Déboguer une erreur d'indentation YAML en la convertissant en JSON

L'étape qui n'a jamais été exécutée : un fichier de workflow bien analysé et une clé qui s'est retrouvée à un niveau trop élevé

Un flux de travail peut être analysé avec succès en plaçant `with` à côté d'une étape plutôt qu'à l'intérieur de celle-ci. Le coureur ignore alors ou rejette la forme plus tard, et l'inspection visuelle manque le décalage car la source reste bien rangée. La conversion en JSON expose le parent réel via des accolades et des limites de tableau.

ToolAcre signale un YAML mal formé avec la ligne et la colonne, mais une structure incorrecte valide ne produit aucune erreur de syntaxe. L'arborescence convertie est donc une vue de diagnostic : elle vous indique ce que cet analyseur a accepté, et non ce que le schéma de workflow voulait.

Pourquoi les erreurs d'indentation ne sont souvent pas des erreurs — La structure de YAML est constituée d'espaces, donc une ligne décalée crée généralement un document valide mais différent

Les espaces portent la hiérarchie YAML. Déplacer une ligne vers la gauche peut transformer un enfant en frère ou sœur ; déplacer un tiret peut placer un élément dans une autre séquence. Les deux documents peuvent satisfaire à la grammaire YAML. La validation syntaxique ne peut pas décider quelle imbrication correspond à l'application.

Les tabulations en indentation sont rejetées par l'analyseur et reçoivent une position. Les espaces qui produisent une hiérarchie valide incorrecte nécessitent plutôt une comparaison structurelle. Cette différence explique pourquoi certaines erreurs d'indentation échouent immédiatement tandis que d'autres survivent jusqu'au comportement de l'application.

Ce que JSON rend explicite : des accolades et des crochets qui montrent précisément à quel objet appartient une clé

JSON écrit les limites des objets avec des accolades et les membres du tableau avec des crochets. Une clé YAML égarée apparaît à l'extérieur de l'objet là où vous l'attendiez, et un tiret devient une limite de tableau difficile à ignorer. L'indentation dans le joli JSON est une présentation ; la ponctuation définit la structure.

La vue révèle également les types résolus. Un scalaire non cité peut être nul, numérique ou booléen selon le schéma sélectionné. Corriger la hiérarchie sans vérifier les valeurs peut laisser un deuxième bug, alors comparez le chemin de la propriété et le type JSON.

Formes courantes de l'erreur : un élément de liste sous le mauvais parent, une clé qui est devenue un frère au lieu d'un enfant et des tabulations mélangées à des espaces

Les erreurs courantes incluent un élément de séquence aligné sur la mauvaise liste, une clé de mappage en retrait vers un frère et des caractères de tabulation mélangés à des espaces. Les clés en double sont un autre piège : ToolAcre conserve la dernière valeur et avertit avec une position, de sorte que JSON ne contient que la propriété survivante.

Les ancres peuvent agrandir le résultat, car les alias se développent en données répétées. Ceci est attendu pour cette conversion et ne doit pas être confondu avec une indentation accidentelle. Lisez les avertissements avant d'attribuer chaque différence structurelle aux espaces.

Exemple concret : un flux de travail CI avec un bloc « with » mal indenté — conversion en JSON, détection de la clé égarée, correction et reconversion

Créez un travail rédigé avec `steps`, une entrée `uses` et un mappage `with`. Supprimez `with` pour qu'il devienne un frère de `steps`, puis convertissez-le. Les accolades JSON montrent que `with` appartient au travail plutôt qu'à l'objet étape. Déplacez-le sous l'élément de liste et reconvertissez-le pour voir l'imbrication prévue.

Cet exemple évite de revendiquer la façon dont un service CI spécifique répond, car le convertisseur ne charge pas ce schéma. La preuve est la hiérarchie analysée. La validation du schéma doit suivre et peut alors indiquer si `with` est accepté sur le chemin corrigé.

Utilisation de la conversion inverse — JSON en YAML pour produire une version correctement indentée que vous pouvez recoller

Une fois la structure JSON correcte, sa reconversion en YAML produit une indentation cohérente à partir du sérialiseur. Les chaînes ambiguës peuvent être placées entre guillemets et les commentaires ne sont pas restaurés. Traitez la sortie comme une sérialisation de données propre, et non comme un formateur préservant la source.

Si les commentaires originaux expliquent des choix opérationnels, copier la structure corrigée dans le fichier maintenu plutôt que de la remplacer aveuglément. Un fichier généré peut être structurellement correct et éditorialement incomplet.

Ce que cela ne couvre pas : validation sémantique par rapport au flux de travail ou au schéma manifeste, qui détecte les clés inconnues plutôt que celles égarées

Aucun workflow, Compose, Kubernetes ou schéma d'application n'est impliqué. Une clé peut se trouver sous le parent prévu et être toujours mal orthographiée ou non prise en charge. Les convertisseurs de syntaxe prouvent uniquement que YAML est accepté et affichent la valeur résultante en forme de JSON.

Utilisez le validateur de la plateforme propriétaire pour les clés inconnues, les champs obligatoires et les contraintes sémantiques. Garder les contrôles de syntaxe et de schéma séparés produit des échecs plus clairs et évite de créditer un convertisseur générique avec des connaissances de domaine qu'il ne possède pas.

À retenir : lorsque YAML semble correct et se comporte mal, considérez-le comme JSON - et comment le panneau des convertisseurs de syntaxe le fait instantanément

Lorsque YAML semble correct mais se comporte mal, inspectez l'arborescence analysée. Les accolades et crochets JSON rendent la filiation explicite, tandis que les avertissements de ToolAcre exposent des doublons, des flux et des changements de valeur qui peuvent compliquer la situation.

Corrigez une erreur de hiérarchie, reconvertissez puis exécutez la validation du schéma. Cette séquence transforme un soupçon d'espace invisible en structure observable sans prétendre qu'une conversion réussie rend la configuration valide pour sa destination.

Lorsque vous comparez avant et après, concentrez-vous sur les chemins de propriété plutôt que sur les numéros de ligne, car la sérialisation peut réorganiser la présentation ou ajouter des guillemets. Une revue utile répertorie le chemin attendu, son type JSON et s'il se trouve à l'intérieur d'un objet ou d'un tableau. Cette petite liste de contrôle détecte une deuxième clé égarée même lorsque le premier symptôme visuel est corrigé, et évite de transformer le formatage YAML généré en oracle de test.