YAML インデントの間違いを JSON に変換してデバッグします

実行されなかったステップ — ワークフロー ファイルは正常に解析され、キーは 1 レベル高すぎました

ワークフローは、`with` をステップ内ではなくステップの横に配置しても正常に解析できます。その後、ランナーはその形状を無視または拒否し、ソースが整然としたままであるため、目視検査ではシフトを見逃します。 JSON に変換すると、中括弧と配列境界を通して実際の親が公開されます。

ToolAcre は、行と列を含む不正な形式の YAML を報告しますが、有効な間違った構造によって構文エラーは発生しません。したがって、変換されたツリーは診断ビューです。ワークフロー スキーマが意図したものではなく、このパーサーが受け入れたものを示します。

インデントの間違いがエラーではないことが多い理由 — YAML の構造は空白であるため、シフトされた行は通常、有効ではあるが異なるドキュメントを作成します

空白は YAML 階層を保持します。行を左に移動すると、子が兄弟に変わる可能性があります。ダッシュを移動すると、項目を別のシーケンスに配置できます。どちらの文書も YAML 文法を満たしている可能性があります。構文検証では、どのネストがアプリケーションに一致するかを判断できません。

インデント内のタブはパーサーによって拒否され、位置を受け取ります。間違った有効な階層を生成するスペースでは、代わりに構造比較が必要です。この違いは、一部のインデント ミスがすぐに失敗する一方で、その他のインデント ミスはアプリケーションの動作まで存続する理由を説明しています。

JSON が明示するもの — キーがどのオブジェクトに属しているかを正確に示す中括弧と括弧

JSON は、オブジェクトの境界を中括弧で書き込み、配列メンバーを中括弧で書き込みます。間違って配置された YAML キーがオブジェクトの外側の予期した場所に表示され、ダッシュが見落としにくい配列境界になります。美しい JSON のインデントはプレゼンテーションです。句読点は構造を定義します。

このビューには、解決されたタイプも表示されます。引用符で囲まれていないスカラーは、選択したスキーマでは null、数値、またはブール値になります。値をチェックせずに階層を修正すると 2 番目のバグが残る可能性があるため、プロパティ パスと JSON タイプの両方を比較してください。

よくある間違いの形状 — 間違った親の下にあるリスト項目、子ではなく兄弟になったキー、およびスペースが混在したタブ

よくある間違いには、シーケンス項目が間違ったリストに配置されている、マッピング キーが兄弟にアウトデントされている、タブ文字とスペースが混在しているなどがあります。重複キーは別の罠です。ToolAcre は最後の値を保持し、位置で警告するため、JSON には生き残ったプロパティのみが含まれます。

エイリアスは繰り返しデータに展開されるため、アンカーを使用すると結果が大きく見えることがあります。これはこの変換では予期されており、偶発的なインデントと混同しないでください。あらゆる構造上の違いが空白のせいだと考える前に、警告を読んでください。

うまくいった例: 1 つのインデントが間違っている 'with' ブロックを含む CI ワークフロー — JSON に変換し、間違って配置されたキーを特定し、修正して再変換する

`steps`、1 つの `uses` エントリ、および `with` マッピングを使用して編集されたジョブを作成します。 `with` をアウトデントして `steps` の兄弟になり、変換します。 JSON 中かっこは、`with` がステップ オブジェクトではなくジョブに属していることを示しています。これをリスト項目の下に移動し、再変換して意図したネストを確認します。

この例では、コンバーターがそのスキーマをロードしないため、特定の CI サービスがどのように応答するかを主張することを避けています。その証拠は、解析された階層です。スキーマ検証はその後に行われ、修正されたパスで `with` が受け入れられるかどうかを報告できます。

逆変換を使用する — JSON から YAML へ、ペーストバックできる正しくインデントされたバージョンを生成します

JSON 構造が正しい場合は、それを YAML に戻すと、シリアライザーから一貫したインデントが生成されます。あいまいな文字列は引用符で囲まれる可能性があり、コメントは復元されません。出力をソースを保持するフォーマッタではなく、クリーンなデータのシリアル化として扱います。

元のコメントが操作上の選択肢を説明している場合は、修正された構造をやみくもに置き換えるのではなく、保守されているファイルにコピーしてください。生成されたファイルは、構造的には正しくても、編集的には不完全である可能性があります。

これでカバーされないもの — ワークフローまたはマニフェスト スキーマに対するセマンティック検証。置き忘れられたキーではなく未知のキーをキャッチします。

ワークフロー、Compose、Kubernetes、またはアプリケーション スキーマは関係しません。キーは、意図された親の下に配置されていても、スペルが間違っていたり、サポートされていない可能性があります。構文コンバーターは、YAML が受け入れられることのみを証明し、結果の JSON 型の値を表示します。

不明なキー、必須フィールド、およびセマンティック制約については、所有するプラットフォームのバリデーターを使用します。構文チェックとスキーマ チェックを分離しておくと、より明確なエラーが生成され、汎用コンバータが持っていないドメイン知識を持っていると認定されるのを避けることができます。

要点: YAML が正しく見えても動作が間違っている場合は、それを JSON として見てください。また、構文コンバーター パネルがそれを即座に行う方法についても説明します。

YAML が正しく見えても動作が間違っている場合は、解析されたツリーを調べてください。 JSON 中括弧と括弧は親子関係を明示しますが、ToolAcre の警告は、状況を複雑にする可能性のある重複、ストリーム、および値の変更を明らかにします。

1 つの階層エラーを修正し、再変換してからスキーマ検証を実行します。このシーケンスは、変換が成功した場合に構成が宛先で有効になると主張することなく、目に見えない空白の疑いを観察可能な構造に変換します。

シリアル化によって表示の順序が変更されたり、引用符が追加されたりする可能性があるため、前後を比較する場合は、行番号ではなくプロパティ パスに注目してください。有用なレビューには、予想されるパス、その JSON タイプ、およびそれがオブジェクト内にあるか配列内にあるかがリストされています。この小さなチェックリストは、最初の視覚的な症状が修正された場合でも、2 番目のキーの置き忘れを検出し、生成された YAML 形式をテスト オラクルに変換することを回避します。