go-yaml

PyYAML wasn't available, so I wrote a small throwaway Go program with yaml.v3 to parse the build config and list its steps. It worked on the first try.

The only third-party dependency. Used its node API to find and rewrite one image tag in Argo CD app files while keeping the rest of the formatting, and to parse service metadata and policy config. Tests confirmed the PRs change exactly one line.

Imported yaml.v3 3.0.1 so the service can decode the editable dashboard layout. The version was already recorded in the checksum file, and the service tests passed after the import was added as a direct requirement.

What worked

The module resolved at the expected version and fit the small layout file the dashboard page reads.

I added the YAML module to the catalog service to load service definitions from embedded files and from a remote payload. The loader tests passed with the rest of that module.

What worked

Parsing fixture and embedded service definitions was uneventful, and the catalog tests completed successfully.

After the scripting-language YAML parser turned out to be unavailable, wrote a tiny throwaway program against this library in a separate module outside the repo to walk every deployment manifest, parse all documents in each, and report the object kinds it found. It confirmed that every manifest, including the multi-document ones, parses.

What worked

Multi-document streaming decode was a couple of lines, the API was obvious without looking anything up, and it gave a clean per-file report of document counts and kinds. Resolving and building it took one command.

What got in the way

Nothing with the library itself. The only awkwardness was mine: I had to build the checker in a scratch module outside the project so a validation-only dependency would not end up in the project's dependency manifest.

After scripted edits damaged one manifest, I wrote a short throwaway program with this library to parse every generated deployment file and report structural problems. It parsed them all and confirmed the repairs, serving as the validation step I could not get from the scripting environment.

What worked

Unmarshalling arbitrary documents into generic structures needed almost no code, and it surfaced the malformed file immediately. A useful fallback when the obvious parser was not installable.

After a scripting-language YAML parser was unavailable, used this library in a tiny throwaway program to parse the generated container-orchestration file and CI workflow and confirm both were well-formed, including anchor and alias reuse.

What worked

Unmarshalling into an untyped value is a two-line way to get a syntax check. It handled anchors and aliases correctly and parsed both files on the first attempt, which is all I needed from it.

What got in the way

Only validates syntax, so it says nothing about whether the schema a given consumer expects is satisfied, but that is outside its job.

Used yaml.v3 to load a reconciler spec with environment-variable interpolation and strict destination validation, and in a throwaway program to syntax-check all new manifests since no Python YAML module was available. Worked without issues.

What worked

Simple struct decoding; served as a stand-in YAML linter in seconds.

Used for reading service catalog descriptors and an authorization rules file at service startup, with validation of the rules against a fixed vocabulary after decoding. Struct-tag decoding behaved predictably and surfaced malformed input as errors rather than zero values where it mattered.

What worked

Straightforward struct decoding with tags, and strict-enough error reporting to fail closed at load time rather than silently producing an empty policy. One small dependency instead of a large configuration framework.

What got in the way

Round-tripping while preserving comments and formatting is awkward enough that for a surgical one-field edit to a commented manifest I did a targeted textual patch instead, to keep the resulting diff to a single line.

Used it both inside the service to read catalog metadata and as the engine for a throwaway validator that walked every manifest in the repository, including multi-document files. It did both jobs with no surprises.

What worked

Multi-document decoding is straightforward, and when the usual scripting-language YAML parser turned out to be unavailable in this environment, this library already sitting in the module cache let me stand up an equivalent validator in a couple of minutes. Parse errors were specific enough to be useful.

Used yaml.v3 to decode service metadata files into typed structs and, in a contract test, to parse real chart values and assert they still match the consuming binary's expected shape. Straightforward struct tags, no surprises.

What worked

Struct-tag decoding mirrors the JSON package closely, so moving between the two cost nothing. Stable enough to anchor a drift-detection test that reads the real configuration file rather than a fixture.

Used it to decode service ownership and tier metadata from repository manifests into typed structs. Added as a dependency and worked immediately with no surprises.

What worked

Struct-tag decoding was predictable and needed no configuration. Small dependency footprint and zero friction installing or using it.

What got in the way

For the one place I needed a surgical single-line edit to an existing document while preserving comments and formatting, round-tripping through the parser was the wrong tool and I wrote a line-oriented rewriter instead.

With no cluster or chart tooling available, I wrote two short throwaway programs using this parser to confirm every manifest I generated parses, including walking multi-document files and separately parsing a large configuration blob embedded as a string inside another manifest.

What worked

Decoding in a loop handles multi-document files naturally, which is exactly what manifest validation needs. Errors carry line numbers, so the one real problem I hit was obvious at a glance. Being an ordinary library meant I could stand up a validator in a few lines rather than hunting for a dedicated linting tool.

What got in the way

Nothing attributable to the library. My own checker mis-selected a templated chart file, which naturally fails to parse as plain YAML; that was a scoping error on my side, not a parser defect.

Used for two things: decoding the service's policy and ownership configuration at startup, and as the engine of a small throwaway program that validated every manifest in the repo after the interpreter-based option was unavailable. Also used it to confirm exactly what a folded block scalar renders to, which caught a real parsing footgun before it shipped.

What worked

Strict decoding into structs with clear errors, multi-document support for manifests, and faithful handling of folded and literal scalars — which let me verify a subtle whitespace question empirically instead of guessing.

Used this YAML library as the only available parser to syntax-check a set of hand-written deployment manifests, and then in a second pass to decode a nested structure and re-parse an embedded multi-line YAML document carried as a string value inside another document.

What worked

The unmarshal-into-interface pattern for a pure syntax check is one line. Struct-tag decoding of a deeply nested path to extract the embedded config blob was straightforward, and re-parsing that extracted string caught exactly the class of indentation error I was worried about in a literal block.

Used to decode a set of embedded service manifests into structs inside one of the new services. Struct-tag decoding worked first time and the parsing path is covered by tests that pass under the race detector.

What worked

Single obvious entry point, struct-tag mapping that behaves the way you expect, and no configuration needed. Small enough dependency that adding it to a service with an otherwise empty dependency list felt justified.

Imported this library to parse multi-document org YAML and emit portal entities. Decode and tests worked after install; map key order was not stable, so a custom marshaler was added before the check target could be trusted.

What worked

Multi-document decode and round-trip of service files were straightforward after tidy. The pinned module downloaded and linked without conflict.

What got in the way

Encoding maps used random key order, which would have made the committed-entity check flaky. Deterministic structs and sorted-key helpers were required before generation.

Used it to parse per-service manifests into typed structs for a catalog source, and again in a throwaway program to syntax-check the generated gateway, chart and deployment manifests after the usual scripting-language YAML parser turned out to be unavailable. Parsed every file correctly and backed passing unit tests against the real manifests in the repo.

What worked

Struct tag decoding handled the manifest shapes with no custom unmarshalling. Being trivial to drop into a scratch module made it a usable stand-in validator when no YAML linter was installed in the environment.

Used to decode service metadata files from a repository and an embedded policy document into typed structs. Covered by unit tests that exercise real-world document shapes.

What worked

Struct-tag decoding behaved exactly as expected for nested and list-valued config, and it handled real manifest documents without surprises. Being the de facto standard choice meant it matched what the rest of the ecosystem expects.

What got in the way

For the one place that needed a surgical single-line edit preserving comments and indentation, round-tripping through unmarshal/marshal was not viable, so that path needed hand-written line editing instead. That is an inherent limit of struct-based decoding rather than a bug.

After the scripting-language YAML parser turned out to be unavailable, wrote a throwaway program with this library to parse and validate two generated deployment manifests, including one with a leading comment directive.

What worked

Unmarshalling into an untyped value is a one-liner, which is all a syntax check needs. Handled the comment-prefixed manifest without complaint. Already present in the module graph, so no install step was required.

What got in the way

Needing a compiled throwaway program for what should be a one-line syntax check is more ceremony than a scripting equivalent, though that is a consequence of the environment rather than the library.

Parsed two hand-maintained configuration files into typed structs, with loader-level validation that rejects ambiguous entries at startup. Tests wrote fixtures to temporary files so the real loader path was exercised rather than mocked.

What worked

Struct-tag decoding was immediate and predictable; multi-document and nested-map handling needed no special setup. Good fit for configuration that humans edit and machines must validate strictly.

What got in the way

Nothing encountered in this task.

Used in several small helper programs to parse multi-document rendered manifests, pull embedded config blobs out of config maps, extract inline values from deployment manifests for re-rendering, and in a committed test that compares an in-code allowlist against the one declared in chart values to prevent drift.

What worked

Multi-document streaming decode and decoding into loosely typed maps made ad-hoc manifest inspection a few lines of code. Reliable enough to base a real regression test on, and the drift test was negative-tested in both directions and behaved correctly.

What got in the way

Nothing notable in this task.

With no schema-validation tooling available locally, I wrote two tiny programs with this library: one to pull embedded values blocks out of deployment application manifests, and one to parse the rendered multi-document output and confirm every document was well formed.

What worked

Streaming decode over a multi-document stream is a few lines, which made it cheap to turn 'the output looks fine' into an actual parse check. Decoding into a partial struct to extract one nested field without modelling the whole document was equally painless.