Config file fixtures (TOML, INI)

TOML Configuration

A TOML configuration file with tables, inline values, and an array of tables — for testing TOML parsers.

File: TOML · Config · UTF-8
Use case: Config parsing

INI Configuration

A classic INI configuration file with sections and key/value pairs — for testing INI parsers.

File: INI · Config · UTF-8
Use case: Config parsing

Config — App Feature Flags (TOML)

Tiny SAMPLE TOML config fixture (app-feature-flags) for parser and twin tests.

File: TOML · Config
Use case: Config parsingEditor testing· Conversion set

Config — App Feature Flags (YAML)

Tiny SAMPLE YAML config fixture (app-feature-flags) for parser and twin tests.

File: YAML · Config
Use case: Config parsingEditor testing· Conversion set

Config — App Feature Flags (JSON)

Tiny SAMPLE JSON config fixture (app-feature-flags) for parser and twin tests.

File: JSON · Config
Use case: Config parsingEditor testing· Conversion set

Config — Database Pool (INI)

Tiny SAMPLE INI config fixture (database-pool) for parser and twin tests.

File: INI · Config
Use case: Config parsingEditor testing· Conversion set

Config — Database Pool (ENV)

Tiny SAMPLE ENV config fixture (database-pool) for parser and twin tests.

File: ENV · Config
Use case: Config parsingEditor testing· Conversion set

Config — Redis Cache (TOML)

Tiny SAMPLE TOML config fixture (redis-cache) for parser and twin tests.

File: TOML · Config
Use case: Config parsingEditor testing· Conversion set

Config — Redis Cache (YAML)

Tiny SAMPLE YAML config fixture (redis-cache) for parser and twin tests.

File: YAML · Config
Use case: Config parsingEditor testing· Conversion set

Config — Logging Levels (INI)

Tiny SAMPLE INI config fixture (logging-levels) for parser and twin tests.

File: INI · Config
Use case: Config parsingEditor testing· Conversion set

Config — Cors Origins (JSON)

Tiny SAMPLE JSON config fixture (cors-origins) for parser and twin tests.

File: JSON · Config
Use case: Config parsingEditor testing· Conversion set

Config — Rate Limit (YAML)

Tiny SAMPLE YAML config fixture (rate-limit) for parser and twin tests.

File: YAML · Config
Use case: Config parsingEditor testing· Conversion set

Config — Smtp Relay (ENV)

Tiny SAMPLE ENV config fixture (smtp-relay) for parser and twin tests.

File: ENV · Config
Use case: Config parsingEditor testing· Conversion set

Config — K8S Resource Snippet (YAML)

Tiny SAMPLE YAML config fixture (k8s-resource-snippet) for parser and twin tests.

File: YAML · Config
Use case: Config parsingEditor testing· Conversion set

Code Config — Docker Compose Snippet

Tiny SAMPLE tooling config snippet (docker-compose-snippet) for editor/linter harnesses.

File: YAML · YAML
Use case: Config parsingEditor testing+1· Conversion set

Code Config — Github Actions Snippet

Tiny SAMPLE tooling config snippet (github-actions-snippet) for editor/linter harnesses.

File: YAML · YAML
Use case: Config parsingEditor testing+1· Conversion set

Code Config — Eslint Flat Snippet

Tiny SAMPLE tooling config snippet (eslint-flat-snippet) for editor/linter harnesses.

File: JS · JavaScript
Use case: Config parsingEditor testing+1· Conversion set

Code Config — Prettier Config

Tiny SAMPLE tooling config snippet (prettier-config) for editor/linter harnesses.

File: JSON · JSON
Use case: Config parsingEditor testing+1· Conversion set

Code Config — Editorconfig Snippet

Tiny SAMPLE tooling config snippet (editorconfig-snippet) for editor/linter harnesses.

File: CONF · YAML
Use case: Config parsingEditor testing+1· Conversion set

Code Config — Tsconfig Strict Snippet

Tiny SAMPLE tooling config snippet (tsconfig-strict-snippet) for editor/linter harnesses.

File: JSON · JSON
Use case: Config parsingEditor testing+1· Conversion set

Sample App .env

Sample App .env — small deterministic fixture for parsers and the in-browser editor.

File: ENV · Config
Use case: Editor testingConfig parsing

Sample Dockerfile

Sample Dockerfile — small deterministic fixture for parsers and the in-browser editor.

File: DOCKERFILE · Config
Use case: Editor testingConfig parsing

mta-sts.txt (RFC 8461 SMTP MTA-STS policy)

An SMTP MTA-STS policy in enforce mode listing three MX patterns, one of them a wildcard, with a seven-day max_age. RFC 8461 specifies CRLF line endings, so this fixture is written with them deliberately - for testing policy parsers that split on bare LF.

File: TXT · Well Known
Use case: Web assetsConfig parsing+1· Conversion set

Matrix server delegation (m.server)

The one-member server-delegation document that lets example.com host its Matrix homeserver at matrix.example.com:8448 without changing user IDs. For testing federation discovery and explicit-port handling.

File: JSON · Well Known · 1 member
Use case: Web assetsJSON parsing+1· Paired fixture

Matrix client discovery (m.homeserver)

The client-side twin of the Matrix delegation pair: homeserver and identity server base URLs plus an unregistered vendor key, which clients must carry through rather than reject. For testing discovery and unknown-member tolerance.

File: JSON · Well Known · 3 members
Use case: Web assetsJSON parsing+1· Paired fixture

Java ResourceBundle .properties — English

A English Java ResourceBundle with MessageFormat patterns, a ChoiceFormat plural, positional arguments, escaped braces and apostrophes, a backslash line continuation, and non-ASCII carried as \uXXXX escapes because .properties is defined as ISO-8859-1. The bytes on disk are pure ASCII.

File: PROPERTIES · Icu · ISO-8859-1, non-ASCII written as \uXXXX escapes
Use case: InternationalizationLocalization catalogs+2· Conversion set

Java ResourceBundle .properties — German

A German Java ResourceBundle with MessageFormat patterns, a ChoiceFormat plural, positional arguments, escaped braces and apostrophes, a backslash line continuation, and non-ASCII carried as \uXXXX escapes because .properties is defined as ISO-8859-1. The bytes on disk are pure ASCII.

File: PROPERTIES · Icu · ISO-8859-1, non-ASCII written as \uXXXX escapes
Use case: InternationalizationLocalization catalogs+2· Conversion set

.NET RESX — composite format strings (English (United States))

A English (United States) resource file built around composite format strings — {0:N2}, {2:P1}, {0:C}, {0:d} and {0:t} — whose rendered output depends entirely on CultureInfo. Includes a whitespace-significant resource guarded by xml:space, and documents the suffixed-key convention .NET falls back on because String.Format has no plural selector.

File: RESX · Dotnet
Use case: InternationalizationLocalization catalogs+1· Conversion set

.NET RESX — composite format strings (German (Germany))

A German (Germany) resource file built around composite format strings — {0:N2}, {2:P1}, {0:C}, {0:d} and {0:t} — whose rendered output depends entirely on CultureInfo. Includes a whitespace-significant resource guarded by xml:space, and documents the suffixed-key convention .NET falls back on because String.Format has no plural selector.

File: RESX · Dotnet
Use case: InternationalizationLocalization catalogs+1· Conversion set

.NET RESX — composite format strings (Arabic (Egypt))

A Arabic (Egypt) resource file built around composite format strings — {0:N2}, {2:P1}, {0:C}, {0:d} and {0:t} — whose rendered output depends entirely on CultureInfo. Includes a whitespace-significant resource guarded by xml:space, and documents the suffixed-key convention .NET falls back on because String.Format has no plural selector.

File: RESX · Dotnet
Use case: InternationalizationLocalization catalogs+1· Conversion set

.NET RESX — composite format strings (Polish (Poland))

A Polish (Poland) resource file built around composite format strings — {0:N2}, {2:P1}, {0:C}, {0:d} and {0:t} — whose rendered output depends entirely on CultureInfo. Includes a whitespace-significant resource guarded by xml:space, and documents the suffixed-key convention .NET falls back on because String.Format has no plural selector.

File: RESX · Dotnet
Use case: InternationalizationLocalization catalogs+1· Conversion set

JUnit XML — Properties Block with Awkward Values

A <properties> block holding an empty value, an escaped ampersand in a branch name and a JVM options string with spaces. Use it to check that build metadata survives extraction with its entities unescaped exactly once.

File: XML · Junit XML · UTF-8
Use case: Metadata testingConfig parsing+1· Conversion set

Coverage — Gate Configuration (JSON)

The threshold configuration the three boundary tracefiles in this group are meant to be judged against: global minimums, one per-path override and an explicit >= comparison. Publishing the comparison operator is the point — leaving it implicit is what makes an at-the-gate report ambiguous.

File: JSON · Coverage
Use case: Config parsingJSON parsing+1· Conversion set

Performance Budget — Page and API Limits (JSON)

A budget file pairing per-path resource-size and timing limits with API latency budgets, including a glob path that must be matched rather than compared for equality. It is the configuration side of the load-test results in this group: the limits a run is judged against.

File: JSON · Performance
Use case: Performance testingConfig parsing+1· Conversion set

MERGE_MSG - Merge Commit Template With a Conflicts Block

The message template git writes into .git/MERGE_MSG when a merge stops on conflicts: one real subject line followed by a commented list of the conflicted paths and the standard advice block. Everything after the first blank line is stripped by `git commit`, so a hook that lints the whole file rejects messages git would accept.

File: TXT · Merges · UTF-8
Use case: Config parsingVisual diff / regression+1

Gitignore - Node Monorepo With Re-Included Artefacts

A realistic monorepo ignore file that uses `dist/*` rather than `dist/` precisely so the two `!dist/...` re-inclusions below it can work. It also carries the `.env.*` / `!.env.example` and `*.log` / `!logs/retained/*.log` pairs that every ignore-matcher has to order correctly.

File: GITIGNORE · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

Gitignore - Negation After a Directory Exclusion (No Effect)

The single most misunderstood rule in the format: once `build/` excludes a directory, git does not descend into it, so `!build/keep.txt` is dead. The file is valid and the behaviour is documented — it is the author's expectation that is wrong, which is exactly why an ignore-matcher must reproduce it rather than being helpful.

File: GITIGNORE · Repo Config · UTF-8
Use case: Config parsingConfig testing+1· Paired fixture

Gitignore - The Working Form of the Same Negation

The corrected twin: `build/*` excludes the directory's contents instead of the directory, so git still descends and `!build/keep.txt` re-includes the file. The two fixtures differ by two characters and produce opposite results, which makes them a precise pass/fail pair for an ignore engine.

File: GITIGNORE · Repo Config · UTF-8
Use case: Config parsingConfig testing+1· Paired fixture

Gitignore - Globstar, Anchors and Character Classes

One pattern per rule in the gitignore grammar: a leading slash that anchors to the containing directory, the same name unanchored, `**` in all three positions, `?` and `[...]` classes, and a trailing slash that matches only directories. Every line is a separate assertion for a matcher's test suite.

File: GITIGNORE · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

Gitignore - Escaped #, !, Bracket and Trailing Space

Every escape the format defines, including the one nobody expects: a trailing space is stripped from a pattern unless it is backslash-escaped, so `draft\ ` and `draft` ignore different files. Editors that trim trailing whitespace on save silently change what this file means.

File: GITIGNORE · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

Gitattributes - End-of-Line Normalisation Rules

The attribute file that decides what happens to line endings on checkout: `text=auto` as the default, explicit `eol=lf` and `eol=crlf` overrides, the `binary` macro that expands to `-text -diff`, and one `-text` entry that is still given a textconv driver. This is the file whose absence causes the CRLF twins elsewhere in this category.

File: GITATTRIBUTES · Repo Config · UTF-8
Use case: Config parsingEncoding detection+1

Gitattributes - LFS Filters, Linguist Hints and export-ignore

The non-EOL half of the format: LFS filter/diff/merge triples, `linguist-generated` and `linguist-vendored` hints that hide files from language statistics and review, `export-ignore` entries that drop paths from `git archive`, and a `merge=union` driver for an append-only changelog. Attribute values are unquoted and space-separated, so column alignment is whitespace a parser must collapse.

File: GITATTRIBUTES · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

Gitconfig - Sections, Quoted Subsections and Shell Aliases

A realistic global config exercising the whole INI-like grammar: bracketed sections, quoted subsection names that are case-sensitive while section names are not, values with size suffixes, a shell alias whose leading `!` changes how the rest is executed, and both comment characters.

File: GITCONFIG · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

Gitconfig - includeIf Conditions in Four Flavours

Every conditional-include form git supports — path prefix, case-insensitive path prefix, branch glob, and a condition on an existing remote URL — plus one unconditional include. Order matters: a later include overrides an earlier one, so a parser that gathers includes into a set rather than a list resolves the wrong identity.

File: GITCONFIG · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

Gitmodules - Three Submodules With Relative URL and branch = .

Three submodules covering the awkward values: a relative `../currency-tables.git` URL that has to be resolved against the superproject's remote, `branch = .` meaning 'the same branch as the superproject', and `ignore = dirty` which hides a submodule's local changes from `git status`. The section name and the `path` value are separate strings and are allowed to differ.

File: GITMODULES · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

CODEOWNERS - Overlapping Globs With Documented Winners

Deliberately overlapping rules so every interesting path matches two or three of them, which is the only way to test that a resolver applies last-match-wins rather than most-specific-wins. One rule has no owners at all, which clears inherited ownership instead of adding any.

File: TXT · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

Mailmap - All Four Rewrite Forms

One line for each of the four rewrite forms git's mailmap supports, including the two-pair form that matches on the commit name as well as the email. Four aliases collapse onto three canonical authors, which is exactly the transformation a shortlog or contributor report has to reproduce.

File: TXT · Repo Config · UTF-8
Use case: Config parsingConfig testing+1

Commit Message - Valid Conventional Commit With Trailers

A commit message file exactly as `git commit` hands it to a commit-msg hook: a conventional subject, a wrapped body, two trailers, and git's own comment block that the hook must ignore. The subject is 43 characters, comfortably inside commitlint's default 72-character header limit.

File: TXT · History · UTF-8
Use case: Config parsingVisual diff / regression+1· Conversion set

Commit Message - Breaking Change With ! and a Footer

A breaking change announced twice, which the specification allows: a `!` after the scope and a `BREAKING CHANGE:` footer whose value continues onto a second line. Generators that stop a footer at the first newline lose half the sentence, and version bumpers that only look for one of the two markers under-bump the release.

File: TXT · History · UTF-8
Use case: Config parsingVisual diff / regression+1· Conversion set

Changelog - Keep a Changelog Layout

A hand-maintained changelog in the Keep a Changelog layout: an Unreleased section, dated version headings in square brackets, the standard change-type subheadings, and reference-style compare links at the bottom. It describes the same releases as the generated twin in this group, so a converter between the two can be scored.

File: MD · History · UTF-8
Use case: Config parsingVisual diff / regression+1· Conversion set

Changelog - Generated From Conventional Commits

The machine-generated twin of the hand-written changelog: version headings that are themselves compare links, a leading warning glyph on the breaking-changes section, and every entry ending in a short-hash link back to the commit. The hashes are the same fictional ids used by the log fixtures in this category.

File: MD · History · UTF-8
Use case: Config parsingVisual diff / regression+1· Conversion set

W3C tracestate — List Members, Limits and Rejects (txt)

tracestate header values covering vendor-prefixed keys, optional whitespace, the exact 32-member limit and a 33-member case that must lose its last member rather than its first — plus duplicate keys, uppercase keys, a bare key and an over-long key that must be rejected.

File: TXT · Traces
Use case: ObservabilitySchema validation+1· Conversion set

B3 Propagation — Single and Multi-Header Forms (txt)

B3 context propagation in both shapes — the compact single b3 header including the debug flag, a legacy 64-bit trace ID and the sampling-only form, plus the five X-B3-* multi-header fields — with two malformed values that must be rejected.

File: TXT · Traces
Use case: ObservabilitySchema validation+1· Conversion set

Prometheus Exposition — Counters and Gauges (prom)

The body a /metrics endpoint returns: five metric families with HELP and TYPE metadata across 27 labelled series — request counters by route and status, process and runtime gauges, per-target up values (one deliberately 0) and a business gauge. The baseline exposition-parser fixture.

File: PROM · Metrics
Use case: ObservabilityTime-series data+1· Conversion set

Prometheus Exposition — Label Value Escaping Edge Cases (prom)

Ten series whose label values contain the characters that break naive line splitting — escaped quotes and backslashes, an escaped newline, non-ASCII text, braces, commas, equals signs, a leading hash and significant whitespace. The exposition format defines exactly three escapes and this file uses all of them.

File: PROM · Metrics
Use case: ObservabilityEncoding detection+1· Conversion set

Prometheus Exposition — Samples with No HELP or TYPE (prom)

Samples exposed with no HELP or TYPE at all, metadata arriving after the sample it describes, blank and whitespace-only lines and a bare comment. All of it is legal — metadata is optional — and all of it breaks parsers that assume every sample is introduced by a TYPE line.

File: PROM · Metrics
Use case: ObservabilityConfig parsing+1· Conversion set

Prometheus Exposition — Empty but Valid Scrape (prom)

A scrape body with metadata but no samples, which is what a freshly started process returns before it has recorded anything. Valid, and routinely mistaken for a failed scrape by code that treats an empty result as an error.

File: PROM · Metrics
Use case: ObservabilityError handling+1· Conversion set

Prometheus Exposition — UTF-8 Quoted Metric and Label Names (prom)

Dotted OpenTelemetry-style metric and label names written with the quoted-name syntax that Prometheus 3 accepts, mixed in one document with a legacy underscore-named family. The fixture for parsers that still assume every name matches [a-zA-Z_][a-zA-Z0-9_]*.

File: PROM · Metrics
Use case: ObservabilityEncoding detection+1· Conversion set

CRI Container Log — Partial Lines and Two Streams (log)

The CRI log format Kubernetes nodes actually write: an RFC 3339 nanosecond timestamp, a stream name, and an F or P tag marking whether the line is full or a partial continuation. One long message is split across several P lines that must be rejoined before parsing.

File: LOG · Logs
Use case: ObservabilityLog parsing+1· Conversion set

systemd Journal — Export Format Entries (log)

Five journal entries in systemd's export format — KEY=value lines separated by blank lines, with the double-underscore address fields, a syslog PRIORITY number rather than a level name, and microsecond timestamps. A parser must map priority 3 to error and 6 to info itself.

File: LOG · Logs
Use case: ObservabilityLog parsing+1· Conversion set

Syslog RFC 5424 — Structured Data Elements (log)

Five RFC 5424 syslog messages with the version digit, a full RFC 3339 timestamp and two structured-data elements per line — including one carrying the trace ID from this category's trace fixtures. The modern syslog most parsers still handle as if it were RFC 3164.

File: LOG · Logs
Use case: ObservabilityLog parsing+1· Conversion set

Prometheus Alerting Rules — Four Rules Across Two Groups (yaml)

Four alerting rules over two groups, using the YAML features that break naive config readers: block scalars for multi-line PromQL, folded scalars for descriptions, Go template annotations with pipes, and keep_firing_for. Every expression references metrics that exist in this category's fixtures.

File: YAML · Alerts
Use case: ObservabilityConfig parsing+1· Conversion set

Prometheus Recording Rules — Layered Pre-Aggregations (yaml)

Five recording rules following the level:metric:operation naming convention, where one rule consumes two others recorded earlier in the same group — evaluation order inside a group is sequential, which is exactly what makes that legal and what a rule validator must understand.

File: YAML · Alerts
Use case: ObservabilityConfig parsing+1· Conversion set

Prometheus Scrape Config — Relabelling and Federation (yaml)

Three scrape jobs with the parts that actually matter: relabel_configs rewriting a target label with a capture group, metric_relabel_configs dropping the two unbounded labels from the cardinality fixture, honor_timestamps for the textfile collector and a federation job with a match[] selector.

File: YAML · Alerts
Use case: ObservabilityConfig parsing+1

Alertmanager Config — Routing Tree, Inhibition and Mute Windows (yaml)

An Alertmanager configuration with the routing behaviour that is hard to reason about without a fixture: a continue: true branch so a critical alert reaches two receivers, an inhibition rule suppressing warnings under a matching critical, and a weekend mute window.

File: YAML · Alerts
Use case: ObservabilityConfig parsing+1

OpenTelemetry Collector — Three-Signal Pipeline Configuration (yaml)

A Collector configuration wiring traces, metrics and logs through separate pipelines, with named component instances, a filelog receiver that parses the CRI log fixture, OTTL statements performing the semantic-convention migration from the paired trace fixtures, and a redaction processor.

File: YAML · Alerts
Use case: ObservabilityConfig parsing+1· Conversion set

OpenTelemetry Collector — Tail-Sampling Policies (yaml)

Six tail-sampling policies including an inverted regex match that drops health checks and a composite policy with its own rate limit and ordered sub-policies. Policies are OR-ed and one match keeps the entire trace, which is the semantic most people get backwards.

File: YAML · Alerts
Use case: ObservabilityConfig parsing+1· Conversion set

Fluent Bit — Tail, Enrich and Forward Pipeline (conf)

A Fluent Bit configuration in its INI-like section format: a tail input using the CRI multiline parser that reassembles the partial-line fixture, Kubernetes enrichment, a modify filter dropping two of the high-cardinality fields, and a throttle. Keys are space-aligned, not delimited.

File: CONF · Alerts
Use case: ObservabilityConfig parsing+1· Conversion set

Vector — Log Topology in TOML with Multi-Line Transforms (toml)

A log-processing topology in TOML where components declare their inputs rather than an explicit graph, including a dropped-event route consumed as parse_json.dropped. The transform bodies are triple-quoted multi-line strings holding a different language, which is what breaks TOML tooling here.

File: TOML · Alerts
Use case: ObservabilityConfig parsing+1· Conversion set

Service Level Objectives — Two SLOs in One Multi-Document YAML (yaml)

Two SLOs — availability and latency — in one multi-document YAML separated by ---, each defined as a ratio of good events to total over a rolling 28-day window. The latency SLO measures the le="1" bucket against the count, which is the correct way to do it from a histogram.

File: YAML · Alerts
Use case: ObservabilityConfig parsing+1· Conversion set

SPDX 2.3 Application SBOM (Tag-Value)

The same SPDX 2.3 SBOM in the specification's plain-text tag-value form — the serialisation many licence-compliance tools still read first, and the exact twin of the JSON document in this family. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Conversion testingConfig parsing+1· Paired fixture

SPDX 2.3 Minimal SBOM (Tag-Value)

An SPDX 2.3 tag-value document with only the mandatory document header and a single fictional package — no relationships, no files — for testing that a parser accepts a document with every optional block absent. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingSchema validation+1· Conversion set

SPDX 2.3 SBOM With File-Level Records

An SPDX 2.3 tag-value SBOM that descends to file level: two fictional build outputs with SHA-1 and SHA-256 checksums, per-file licence findings, and CONTAINS relationships back to their package. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingConversion testing+1· Conversion set

SPDX 2.3 SBOM Relationship Graph (Tag-Value)

An SPDX tag-value SBOM emphasising its relationship block: one DESCRIBES edge and ten DEPENDS_ON edges that form the same two diamonds as the CycloneDX graph fixture. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingGraph data+1· Conversion set

SPDX 2.3 SBOM With LicenseRef and Compound Expressions

An SPDX tag-value SBOM that declares a non-standard LicenseRef with its extracted text and uses it inside compound expressions — the case that breaks compliance tools which assume every licence is an SPDX id. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingSchema validation+1· Conversion set

SPDX Tag-Value SBOM, Truncated — Intentionally Corrupt

An intentionally corrupt SPDX tag-value document, cut off part-way through a tag name so the final line has no colon or value. Kept small on purpose. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Error handlingConfig parsing· Conversion set

SPDX 2.2 Legacy SBOM (Tag-Value)

The same fictional tree as an SPDX 2.2 tag-value document — the version still produced by older toolchains — for upgrade and compatibility tests against the 2.3 twin in this family. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingConversion testing+1· Conversion set

SPDX Container Image SBOM (Tag-Value)

An SPDX tag-value SBOM whose document name is a fictional container image digest rather than an application version — the naming convention image scanners use, and the SPDX counterpart of the CycloneDX container fixture. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: SPDX · Sbom
Use case: Config parsingConversion testing· Conversion set

SPDX 2.3 Application SBOM (YAML)

The SPDX 2.3 SBOM in its YAML serialisation — the third form the specification defines alongside JSON and tag-value, and the one most often hand-edited in a repository. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: YAML · Sbom
Use case: Conversion testingConfig parsing+1· Conversion set

yarn.lock (Classic v1)

A Yarn 1 lockfile in its own line-oriented grammar — quoted descriptor headers, two-space indented fields, resolved URLs with a SHA-1 fragment — which looks like YAML but is not. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

yarn.lock (Berry, __metadata version 8)

A modern Yarn Berry lockfile: YAML-shaped with an __metadata header, npm: protocol resolutions and cache-key-prefixed checksums — deliberately different from the Classic file in the same family. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

pnpm-lock.yaml (lockfileVersion 9)

A pnpm v9 lockfile with its three-section layout — importers for declared specifiers, packages for resolution metadata and snapshots for the resolved edges — pinning the same fictional tree. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: YAML · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

bun.lock (Text Lockfile)

Bun's text lockfile, where each package is a positional array of descriptor, dependency map and integrity string rather than an object — a shape that breaks parsers assuming every lock entry is keyed. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: JSON parsingConfig parsing+1· Conversion set

pip requirements.txt With Pinned Hashes

A hash-pinned pip requirements file with two sha256 hashes per fictional package (wheel and sdist) and line continuations — the form `--require-hashes` installs demand. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: TXT · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

pip constraints.txt

A pip constraints file pinning the same nine fictional packages. Constraints bound a resolution without adding dependencies, so a tool that treats this like requirements.txt installs nine packages too many. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: TXT · Lockfiles
Use case: Config parsingConversion testing· Conversion set

pip-compile Annotated requirements.txt

A pip-compile output where every pin carries a `# via` annotation naming the requirement that pulled it in — the only place the transitive graph survives in a pip workflow. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: TXT · Lockfiles
Use case: Config parsingGraph data+1· Conversion set

Pipfile.lock (Pipenv)

A Pipenv lockfile in JSON, with the _meta hash that ties it to its Pipfile, a named index source and nine fictional pinned packages in the default section. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: JSON parsingConfig parsing+1· Conversion set

poetry.lock (TOML)

A Poetry lockfile: TOML array-of-tables entries with per-artifact sha256 hashes, a [package.dependencies] table per package and the content-hash that binds the lock to pyproject.toml. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

uv.lock (TOML)

A uv lockfile in TOML, recording an sdist and a wheel per fictional package with inline tables carrying url, hash and byte size — a newer layout than poetry.lock and a useful contrast for parser tests. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing· Conversion set

conda Explicit Environment Lock

A conda explicit lock: an @EXPLICIT marker followed by one fully-resolved URL per fictional package with an md5 fragment — no solver involved, which is exactly what makes it a lockfile. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: TXT · Lockfiles
Use case: Config parsingConversion testing· Conversion set

Cargo.lock (version 4)

A Rust Cargo.lock in the version 4 format — TOML [[package]] tables with a registry source, a sha256-shaped checksum and a name-only dependencies array that resolves against the other tables. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

Cargo.lock (version 3, Legacy)

The same fictional Rust tree pinned by a version 3 Cargo.lock, for testing that a reader keys on the declared version rather than assuming the newest format. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing· Conversion set

Cargo.lock, Truncated — Intentionally Corrupt

An intentionally corrupt Cargo.lock: a valid version 4 lockfile cut off inside a [[package]] table so the final key/value pair is incomplete. Small on purpose. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Error handlingConfig parsing· Conversion set

go.mod Module Manifest (as .txt)

A Go module manifest with separate direct and // indirect require blocks for the fictional tree. Served with a .txt extension because go.mod has no registered media type; the content is verbatim go.mod syntax. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: TXT · Lockfiles
Use case: Config parsingConversion testing· Conversion set

go.sum Checksum Lines (as .txt)

go.sum content: two h1: lines per fictional module — one for the module zip and one for its go.mod — which is the pairing a verifier must require. Served as .txt because go.sum has no registered media type. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: TXT · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

composer.lock (PHP)

A PHP composer.lock in JSON, pinning each fictional package by both a git reference and a dist zip shasum, with a content-hash binding it to composer.json. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: JSON parsingConfig parsing+1· Conversion set

Gemfile.lock (Bundler)

A Bundler lockfile in its indentation-significant block format — specs nested under GEM, transitive requirements nested one level deeper, and the BUNDLED WITH version on its own indented line. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

Podfile.lock (CocoaPods)

A CocoaPods lockfile: a YAML-subset document listing pods with their nested requirements, a SPEC CHECKSUMS block of SHA-1 values and the CocoaPods version that produced it. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing· Conversion set

mix.lock (Elixir)

An Elixir mix.lock: a literal Elixir map whose values are tuples of atoms, strings and lists. It is neither JSON nor TOML, so a generic lockfile reader has to special-case it. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing+1· Conversion set

pubspec.lock (Dart/Flutter)

A Dart pubspec.lock in YAML, labelling each fictional package as direct main or transitive and recording a sha256 in its description block along with the SDK constraint. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing· Conversion set

packages.lock.json (NuGet)

A NuGet lockfile keyed by target framework, distinguishing Direct from Transitive entries and recording a base64 contentHash for each fictional package. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: JSON · Lockfiles
Use case: JSON parsingConfig parsing+1· Conversion set

Gradle Dependency Lockfile

A Gradle dependency lockfile: one `group:artifact:version=configurations` line per fictional module plus the `empty=` line that records configurations resolving to nothing. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: LOCK · Lockfiles
Use case: Config parsingConversion testing· Conversion set

Vulnerability Suppression Policy (YAML)

A suppression policy that gives every waiver an owner, a reason and an expiry date — the fields that stop a suppression file becoming a permanent blindfold. All four entries are SAMPLE. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.

File: YAML · Vulnerability
Use case: Config parsingConfig testing+1· Conversion set

Release SHA256SUMS Manifest

The oldest supply-chain artifact there is: a sha256sum manifest with the exact two-space separator the tool emits, listing a fictional release tarball and its nine dependency archives. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: TXT · Provenance
Use case: Config parsingConversion testing+1· Conversion set

Detached Signature, ASCII Armor — SAMPLE Shape

An ASCII-armored detached signature block of the shape that accompanies a SHA256SUMS file. It is a SAMPLE placeholder, not a valid OpenPGP signature — armor detectors will find it, verifiers must reject it. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

File: TXT · Provenance
Use case: Config parsingCertificate & key testing+1· Conversion set

Attestation Verification Policy (YAML)

The policy an admission controller evaluates before an artifact is allowed through: required predicate types, an allowed-builder list, a minimum SLSA level, a transparency-log requirement and one dated exception. Every package, version, hash and licence is fictional — the tree describes nothing real.

File: YAML · Provenance
Use case: Config parsingConfig testing+1· Conversion set

GitHub Actions Node Matrix Workflow

A GitHub Actions CI workflow with a two-axis build matrix (three Node versions across two runners), an npm cache, and a conditional artifact upload. Six matrix combinations, so a workflow linter or matrix expander has a documented answer to check against.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions Reusable Workflow (workflow_call)

The called half of a reusable-workflow pair: a workflow_call trigger with typed inputs, a default value, and a declared output wired to a job output. Pair it with the caller fixture to test cross-workflow input and output resolution.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions Reusable Workflow Caller

The calling half of a reusable-workflow pair: a workflow_dispatch trigger with a choice input, two jobs that call the same reusable workflow with different arguments, and a third that consumes their outputs through needs.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions Composite Action Definition

An action.yml-shaped composite action definition with typed inputs, a declared output bound to a step output, and a branding block. Distinct from a workflow file, and a common blind spot in workflow linters that only understand .github/workflows.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions on: Key YAML Boolean Trap

The workflow file that exposes the YAML 1.1 boolean resolver: a bare `on` key becomes True in PyYAML, SnakeYAML and Psych, so a round-trip through those loaders loses the trigger block. The env values repeat the trap with NO, yes and off alongside a quoted control.

File: YML · Github Actions
Use case: Config parsingEncoding detection+1

GitHub Actions Deprecated Workflow Commands

A deprecated-syntax workflow: ::set-output, ::set-env and ::add-path markers, a retired runner label, and v2 action pins. Every construct here was removed from the runner, so an upgrade migrator can be scored on whether it rewrites all of them.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions Over-Permissive Token (Policy Target)

A schema-valid workflow that should still be rejected on review: permissions: write-all at the workflow level plus three unused write scopes on the job. Nothing here is an exploit; it is the least-privilege finding a policy engine is supposed to raise.

File: YML · Github Actions
Use case: Config testingSchema validation+1

GitHub Actions Concurrency and Environment

A deployment workflow exercising the blocks that governance tools care about: a concurrency group with cancel-in-progress, paths-ignore filters, a named environment with a URL, and a job timeout. All hosts are example.invalid.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions Expression and Function Coverage

An expression-dense workflow: fromJSON-generated matrix axes, hashFiles cache keys, format and join calls, a folded multi-line if condition, and the && / || coalescing idiom that stands in for a ternary. For testing template resolvers before any schema check.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions Matrix Include and Exclude

The matrix case that expanders get wrong: a 3x3 base grid, two exclude rules, and one include entry that adds a combination and an extra key. Nine minus two plus one is eight jobs, documented in the specs so an expansion can be scored exactly.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions Scheduled Workflow with Dispatch Inputs

A scheduled workflow with two cron entries plus a manual workflow_dispatch trigger carrying a boolean and a choice input. For testing cron parsers, trigger extraction, and input-type handling in workflow tooling.

File: YML · Github Actions
Use case: Config testingConfig parsing+1

GitHub Actions Workflow, Intentionally Invalid

An intentionally invalid GitHub Actions workflow: well-formed YAML that breaks the workflow schema in four documented ways — no jobs mapping, a scalar `on`, a mapping `runs-on`, and a step carrying both uses and run. For testing that a validator rejects, and reports why.

File: YML · Github Actions
Use case: Error handlingConfig parsing+1

GitLab CI Stages, Needs, and Artifacts

A three-stage GitLab CI pipeline with a default block, global variables, artifact expiry, a needs-based DAG, and a coverage-extraction regex. The baseline the other GitLab fixtures vary from.

File: YML · Gitlab Ci
Use case: Config testingConfig parsing+1

GitLab CI Anchors and Extends

The two GitLab inheritance mechanisms in one file: YAML anchors with merge keys, which the loader resolves before GitLab sees the document, and `extends`, which GitLab resolves afterwards with a deep merge. Hidden .job keys carry both.

File: YML · Gitlab Ci
Use case: Config parsingEncoding detection+1

GitLab CI !reference Custom YAML Tag

GitLab's `!reference` custom YAML tag used three ways: inside a script list, as a whole after_script value, and as a whole rules value. A stock YAML 1.2 loader has no constructor for it and raises; GitLab's loader resolves each key path.

File: YML · Gitlab Ci
Use case: Config parsingEncoding detection+1

GitLab CI Rules and Workflow Conditions

Rule-driven GitLab CI: a workflow block with four ordered conditions ending in `when: never`, plus job rules combining changes patterns, regex tag matching, a null-branch comparison, and a manual allow-failure fallback.

File: YML · Gitlab Ci
Use case: Config testingConfig parsing+1

GitLab CI Include Resolution

Five include entries across the four include kinds — local path, local glob, another project at a pinned ref, a remote URL, and a bundled template. For testing include resolvers and dependency graphing without any file actually being fetched.

File: YML · Gitlab Ci
Use case: Config testingConfig parsing+1

GitLab CI Parallel Matrix Expansion

Both GitLab parallelisation forms in one file: a plain `parallel: 4` shard split and a `parallel: matrix` block whose two entries expand to seven combinations. Eleven jobs in total, documented so an expander can be checked exactly.

File: YML · Gitlab Ci
Use case: Config testingConfig parsing+1

GitLab CI Deprecated only/except Syntax

A deprecated-syntax GitLab CI file using `only`/`except` in both the array and keyed forms, plus the long-retired `type:` keyword. For scoring a migrator that must rewrite all of it to `rules` and `stage`.

File: YML · Gitlab Ci
Use case: Config testingConfig parsing+1

GitLab CI Child and Downstream Triggers

Dynamic child pipelines and a cross-project downstream trigger: one job generates a pipeline file as an artifact and a trigger job includes it, while a second trigger job starts a downstream project's pipeline with strategy: depend.

File: YML · Gitlab Ci
Use case: Config testingConfig parsing+1

GitLab CI Config, Intentionally Invalid

An intentionally invalid GitLab CI config: valid YAML with a misspelled `stagess` key, a job naming an undeclared stage, a job with no script, and an `only:` given a bare scalar. For testing that a linter rejects it and names each fault.

File: YML · Gitlab Ci
Use case: Error handlingConfig parsing+1

CircleCI Config with Cache and Workspace

A CircleCI 2.1 config with a two-job workflow, a fallback cache-key list, workspace persistence between jobs, and a test-results store. The baseline the other CircleCI fixtures vary from.

File: YML · Circleci
Use case: Config testingConfig parsing+1

CircleCI Orbs and Named Executors

CircleCI orbs and reusable named executors: two orb imports, two executors at different resource classes, an orb-provided step, and a branch filter combining an exact name with a regex.

File: YML · Circleci
Use case: Config testingConfig parsing+1

CircleCI Reusable Commands and Parameters

A reusable CircleCI command with string and boolean parameters, a conditional `when` step, and a job parameterised by an enum expanded through a workflow matrix. Exercises CircleCI's << >> template syntax, which is not YAML and not Jinja.

File: YML · Circleci
Use case: Config testingConfig parsing+1

CircleCI Workflow Matrix with Exclude

A CircleCI workflow matrix across three operating systems and two Go versions with one exclusion, plus a tag filter regex. Six combinations minus one is five jobs, documented so an expansion can be scored exactly.

File: YML · Circleci
Use case: Config testingConfig parsing+1

CircleCI Config, Intentionally Invalid

An intentionally invalid CircleCI config: an unquoted `version: 2.10` that YAML loads as the float 2.1, a workflow referencing an undefined job, and a job with no execution environment. For testing that a validator rejects it and explains each fault.

File: YML · Circleci
Use case: Error handlingConfig parsing+1

Azure Pipelines Steps and Triggers

The simplest Azure Pipelines shape: no stages or jobs, just a trigger with branch and path filters, a PR trigger, variables, and a flat step list mixing task and script steps. Baseline for the stage-based fixtures.

File: YML · Azure Pipelines
Use case: Config testingConfig parsing+1

Azure Pipelines Stages and Deployment Job

A three-stage Azure Pipelines definition with a build-number format expression, a variable group reference, stage conditions built from the expression functions, and a deployment job using the runOnce strategy against a named environment.

File: YML · Azure Pipelines
Use case: Config testingConfig parsing+1

Azure Pipelines Template Expressions and Parameters

Compile-time template expressions: an `${{ each }}` loop over an object parameter, an `${{ if }}` conditional insertion, an `extends` template, and a step template with arguments. These resolve before runtime, which template-aware linters must model.

File: YML · Azure Pipelines
Use case: Config testingConfig parsing+1

Azure Pipelines Matrix Strategy

Azure's named-leg matrix form, where each leg is a mapping of variables rather than an axis product: three Python legs, a maxParallel cap, a job timeout, and a JUnit results publish step that runs on failure too.

File: YML · Azure Pipelines
Use case: Config testingConfig parsing+1

Azure Pipelines, Intentionally Invalid

An intentionally invalid Azure Pipelines file: valid YAML that mixes top-level steps with a stages block, depends on an undeclared stage, and gives `pool` a bare string. For testing that a validator rejects it and reports all three faults.

File: YML · Azure Pipelines
Use case: Error handlingConfig parsing+1

Jenkinsfile, Declarative Pipeline

A declarative Jenkinsfile with a docker agent, options, environment and parameters blocks, a parallel test stage gated by a when expression, and post conditions. The dialect most Jenkins linters target.

File: JENKINSFILE · Jenkins
Use case: Config testingConfig parsing+1

Jenkinsfile, Scripted Pipeline

The scripted Jenkinsfile dialect: an imperative node block with Groovy variables, a for loop that builds a parallel branch map at runtime, and try/catch error collection. Structurally unlike the declarative form, and a common parser gap.

File: JENKINSFILE · Jenkins
Use case: Config testingConfig parsing+1

Jenkinsfile Matrix with Excludes

A declarative Jenkins matrix over two axes with a nested excludes block: six platform/arch combinations minus the windows arm64 pair leaves five cells, documented in the specs so an expansion can be scored exactly.

File: JENKINSFILE · Jenkins
Use case: Config testingConfig parsing+1

Jenkinsfile with Shared Library

A Jenkinsfile importing a pinned shared library and calling three custom steps that no static parser can resolve locally. For testing how tooling reports unknown steps and whether it records the library dependency and its version pin.

File: JENKINSFILE · Jenkins
Use case: Config testingConfig parsing+1

Jenkinsfile, Intentionally Invalid

An intentionally invalid Jenkinsfile: an unclosed stage block so braces never balance, a steps block outside any stage, and a bare identifier where the agent directive needs any, none, or a block. For testing parser error recovery and reporting.

File: JENKINSFILE · Jenkins
Use case: Error handlingConfig parsing+1

Kubernetes Multi-Document Manifest Bundle

Three Kubernetes objects in one YAML stream, the shape kubectl apply consumes. A loader that calls the single-document API returns only the first object and silently drops the other two, which is exactly the failure this fixture is for.

File: YAML · Kubernetes
Use case: Config testingConfig parsing+1

Kubernetes StatefulSet with Volume Claim Templates

A StatefulSet with volumeClaimTemplates, an ordered pod-management policy, a partitioned rolling update, and a non-root pod security context. For testing manifest linters and admission policies that reason about storage and identity.

File: YAML · Kubernetes
Use case: Config testingConfig parsing+1

Kubernetes CronJob Schedule and History Limits

A CronJob with an explicit timeZone, Forbid concurrency, a starting deadline, and history limits on both success and failure. For testing cron parsing and the scheduling fields policy engines most often check.

File: YAML · Kubernetes
Use case: Config testingConfig parsing+1

Kubernetes HorizontalPodAutoscaler (autoscaling/v2)

An autoscaling/v2 HPA with both a Resource and a Pods metric, plus scaleUp and scaleDown behaviour policies. The v2 metric shape differs sharply from v1 and v2beta, which is what makes it a useful conversion fixture.

File: YAML · Kubernetes
Use case: Config testingConfig parsing+1

Kubernetes NetworkPolicy with Ingress and Egress

A NetworkPolicy with both policy types: an ingress rule combining namespace and pod selectors, and two egress rules, one of which uses an ipBlock with an except range. For testing policy engines that reason about allowed traffic.

File: YAML · Kubernetes
Use case: Config testingConfig parsing+1

Kubernetes Namespace, ResourceQuota, and LimitRange

A three-document governance bundle. Its real edge case is quantity handling: values like "8", 16Gi and 250m are Kubernetes quantity strings, and a parser that coerces the quoted ones to numbers or normalises the suffixed ones changes their meaning.

File: YAML · Kubernetes
Use case: Config testingConfig parsing+1

Kubernetes Kustomization Overlay

A Kustomize overlay with a name prefix and suffix, common labels, an image tag override, a configMapGenerator merge, and a JSON-6902 patch embedded as a block scalar — YAML inside YAML, which naive rewriters mangle.

File: YAML · Kubernetes
Use case: Config testingConfig parsing+1

Kubernetes Manifest, Intentionally Invalid

An intentionally invalid Kubernetes manifest: a removed apiVersion, a quoted string where replicas needs an integer, a selector that does not match the pod template, and containers as a mapping instead of a list. Four documented faults for a validator to report.

File: YAML · Kubernetes
Use case: Error handlingConfig parsing+1

Helm Chart.yaml with Dependencies

A Helm v2 Chart.yaml with two conditional subchart dependencies, semver range constraints, a kubeVersion constraint, maintainers and annotations. Every repository and URL is example.invalid, so nothing resolves anywhere real.

File: YAML · Helm
Use case: Config testingConfig parsing+1· Conversion set

Helm Default values.yaml

The defaults half of a Helm values pair: nested maps, an empty map and an empty list, a list of env entries, and quoted booleans that must survive as strings. Pairs with the production overrides fixture for deep-merge testing.

File: YAML · Helm
Use case: Config testingConfig parsing+1· Conversion set

Helm Production values Overrides

The overrides half of a Helm values pair, built to exercise all three merge behaviours at once: maps merge key by key, the env list replaces the defaults wholesale, and an explicit null deletes the inherited podAnnotations map.

File: YAML · Helm
Use case: Config testingConfig parsing+1· Conversion set

Argo CD Application with Sync Policy

An Argo CD Application with automated sync, prune and self-heal, retry backoff, sync options, and an ignoreDifferences rule that exempts replica counts from drift detection. All Git and cluster endpoints are example.invalid.

File: YAML · Argo Tekton
Use case: Config testingConfig parsing+1

Argo CronWorkflow Schedule

An Argo CronWorkflow wrapping an inline workflowSpec: a cron schedule with an explicit timezone, Replace concurrency, history limits, and a suspend flag. Nested-spec shape that flat schedule extractors miss.

File: YAML · Argo Tekton
Use case: Config testingConfig parsing+1

Tekton Task with Params, Workspaces, and Results

A Tekton Task declaring string and array params, a workspace, a result, and two steps that use Tekton's $(params.x) and $(workspaces.x.path) variable syntax, including the $(params.flags[*]) array expansion form.

File: YAML · Argo Tekton
Use case: Config testingConfig parsing+1

Tekton Pipeline with when and finally

A Tekton Pipeline chaining three tasks with runAfter, a when expression that consumes a prior task's result, and a finally task that runs regardless of outcome. The finally block is a common omission in Tekton graph extractors.

File: YAML · Argo Tekton
Use case: Config testingConfig parsing+1

Tekton PipelineRun (Run Request)

A Tekton PipelineRun as a run request: a pipelineRef, params, timeouts and a workspace binding, with no status block. A completed run's status is a record of what happened and belongs with test-report fixtures, not with pipeline definitions.

File: YAML · Argo Tekton
Use case: Config testingConfig parsing+1

Pipeline DAG with a Cycle (JSON), Intentionally Invalid

The shared topology plus one back edge, making it intentionally invalid as a DAG. The document publishes the cycle it contains, so a scheduler or graph validator can be tested on both detecting the cycle and naming it.

File: JSON · Airflow
Use case: Error handlingConfig parsing+1

CWL CommandLineTool Definition

A CWL v1.2 CommandLineTool with typed inputs, positional and prefixed bindings, a JavaScript outputEval expression, resource requirements, a Docker hint, and an IANA $namespaces block. Inert: it describes an invocation and runs nothing.

File: CWL · Cwl
Use case: Config testingConfig parsing+1

CWL Workflow, Intentionally Invalid

An intentionally invalid CWL document: a nonexistent cwlVersion, an unknown class, a step consuming an output no step produces, and outputs given as a bare string. Four documented faults for a CWL validator to report.

File: CWL · Cwl
Use case: Error handlingConfig parsing+1

Terraform Required Providers and Backend

The terraform settings block: a version constraint range, two pinned providers, a local backend, default tags, and a second aliased provider configuration. The fictional examplecloud provider means nothing resolves to a real service.

File: TF · Terraform
Use case: Config testingConfig parsing+1

Terraform Variables with Validation Blocks

Seven Terraform variables covering string, number, map and a map(object) with an optional attribute and a default, plus two validation blocks with error messages. The sensitive variable's default is explicitly a SAMPLE note, not a credential.

File: TF · Terraform
Use case: Config testingConfig parsing+1

Terraform Resources with count and for_each

The resource graph: a network, a for_each subnet set, a counted instance resource, a data source, and a bucket on an aliased provider. Both repetition meta-arguments appear, plus lifecycle and an explicit depends_on edge.

File: TF · Terraform
Use case: Config testingConfig parsing+1

Terraform Locals, for Expressions, and dynamic Blocks

The expression-heavy half of the stack: for expressions producing both a map and a filtered list, conditional expressions selecting whole objects, and a dynamic block that generates two firewall rules from a local list.

File: TF · Terraform
Use case: Config testingConfig parsing+1

Terraform Module Calls with Meta-Arguments

Three module calls covering the shapes a dependency grapher has to handle: a local path with explicit provider passing, a versioned registry source under for_each, and a count-gated conditional module.

File: TF · Terraform
Use case: Config testingConfig parsing+1

Terraform Outputs and Splat Expressions

Five Terraform outputs exercising a splat expression over a counted resource, a for expression over a for_each module, and a sensitive output that must stay redacted when propagated from a sensitive input.

File: TF · Terraform
Use case: Config testingConfig parsing+1

Terraform Default terraform.tfvars

A terraform.tfvars assigning the staging defaults, including a nested map-of-objects value. Pairs with the production overrides file, which replaces that map wholesale rather than merging into it.

File: TFVARS · Terraform
Use case: Config testingConfig parsing+1

Terraform Production tfvars Overrides

The production tfvars overrides. Its point is a semantic that surprises people: a complex-typed variable is replaced whole, not deep-merged, so the staging app-b subnet does not survive the override.

File: TFVARS · Terraform
Use case: Config testingConfig parsing+1

Terraform Configuration, Intentionally Invalid

An intentionally invalid Terraform configuration: an unclosed resource block, a colon where HCL needs an equals sign, a reference to an undeclared resource, and a resource block missing its second label. Four documented faults for a parser to report.

File: TF · Terraform
Use case: Error handlingConfig parsing+1

HCL2 Image Build Definition

A generic HCL2 image-build definition exercising the grammar rather than any vendor schema: labelled blocks, a list variable, locals, an indent-stripping heredoc with an interpolation inside it, and a for expression producing a list.

File: HCL · Hcl
Use case: Config testingConfig parsing+1

HCL2 Orchestrator Job Definition

A deeply nested HCL2 job definition — job, group, task, service, check — with duration strings, a port mapping, and restart and update policies. Four levels of block nesting, which is where hand-rolled HCL readers usually break.

File: HCL · Hcl
Use case: Config testingConfig parsing+1

HCL2 Policy Document

A generic HCL2 policy document with three severity-graded rules, condition blocks using all_of / none_of / one_of, and a dated exemption. Grants nothing to anything; it exists so policy tooling has a realistic document to read.

File: HCL · Hcl
Use case: Config testingConfig parsing+1

HCL2 Document, Intentionally Invalid

An intentionally invalid HCL2 document: an unclosed block, a colon assignment, a half-quoted block label, and a heredoc whose terminator is misspelled so it swallows the remainder of the file. Four documented faults, each a distinct recovery test.

File: HCL · Hcl
Use case: Error handlingConfig parsing+1

Docker Compose Specification (No version Key)

A Compose Specification file with no top-level version key, condition-based depends_on, healthchecks, and a deploy resource limit. Parsers written against the older schema often require the version key, which is exactly what this fixture separates.

File: YAML · Docker
Use case: Config testingConfig parsing+1

Docker Compose Anchors and x- Extension Fields

Compose with three x- extension fields carrying YAML anchors that are merged into services. The trap is ordering: a tool that strips x- keys before parsing the YAML destroys the anchors and the file stops resolving.

File: YAML · Docker
Use case: Config parsingEncoding detection+1

Docker Compose Profiles

Five Compose services across three profiles, one of which belongs to two profiles at once. Services with no profiles key always start; the rest are opt-in, which is the selection logic this fixture exists to test.

File: YAML · Docker
Use case: Config testingConfig parsing+1

Docker Compose File, Intentionally Invalid

An intentionally invalid Compose file: services as a list, a service with both image and an empty build, an unquoted 8080:8080 port that YAML 1.1 reads as a base-60 integer, and a depends_on naming an undefined service.

File: YAML · Docker
Use case: Error handlingConfig parsing+1

Dockerfile, Multi-Stage Build Definition

A three-stage Dockerfile with a syntax directive, build args interpolated into FROM lines, a heredoc COPY, multi-line LABEL and ENV continuations, a non-root USER, and HEALTHCHECK in exec form. Inert: every base image is a fictional example.invalid reference.

File: DOCKERFILE · Docker
Use case: Config parsingSyntax highlighting+1

Makefile Targets and TAB Indentation

A Makefile whose recipe lines are indented with real TAB characters, as make requires. Covers simple, conditional, appended and substitution-reference variables, .PHONY, and .DEFAULT_GOAL. Every recipe is echo-only, so running it does nothing.

File: MK · Build
Use case: Config parsingSyntax highlighting+1

Makefile Pattern Rules and Conditionals

Pattern rules with the automatic variables $@, $<, $^ and $*, ifeq/ifdef conditional directives, a vpath search path, and a define block invoked through $(call). All recipe lines are TAB-indented and echo-only.

File: MK · Build
Use case: Config parsingSyntax highlighting+1

Makefile with Space Indentation, Intentionally Invalid

An intentionally invalid Makefile whose recipe lines are indented with four spaces instead of the required TAB. This is the most common Makefile defect there is, and it is invisible in most editors — which is exactly why it belongs in a fixture set.

File: MK · Build
Use case: Error handlingConfig parsing+1

Gradle Build Script (Groovy DSL)

A Gradle Groovy DSL build script with a plugins block, a Java toolchain, five dependency configurations, task configuration via named() and a registered task. Every coordinate and repository is fictional, so nothing resolves.

File: GRADLE · Build
Use case: Config parsingSyntax highlighting+1

Gradle Settings Script with Version Catalog

A Gradle settings script — the file that actually defines a multi-project build — with pluginManagement, a repositories mode, a version catalog declaring libraries, a bundle and a plugin, and one project remapped to a custom directory.

File: GRADLE · Build
Use case: Config parsingSyntax highlighting+1

gradle.properties with Escapes and Continuations

A gradle.properties exercising the .properties grammar rather than Gradle: a \uXXXX escape, a backslash line continuation, all three key/value separator forms, and a key containing escaped separator characters.

File: PROPERTIES · Build
Use case: Config parsingSyntax highlighting+1

Java Properties Parser Edge Cases

The .properties edge cases collected in one file: both comment markers, empty values, a value whose trailing spaces are significant, unescaped = and : inside values, a # that is not a comment, escape sequences, an escaped space in a key, and a duplicate key.

File: PROPERTIES · Build
Use case: Config parsingSyntax highlighting+1

TOML Build Configuration with Array of Tables

A build-tool configuration in TOML, chosen for the constructs YAML has no direct equivalent for: three [[build.step]] array-of-tables entries carrying an ordered pipeline, a quoted glob key, and all three TOML date-time flavours.

File: TOML · Build
Use case: Config parsingSyntax highlighting+1

YAML Anchors and Aliases

Anchors and aliases across mapping, sequence and scalar nodes, including an anchor nested inside another anchored node. The point most tooling misses: an alias is a reference to the same node, so a shallow-loading parser can share mutable state between jobs.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Merge Keys and Precedence

Merge keys with their full precedence rules: local keys beat merged ones, and in a merge sequence the earlier alias wins. The file publishes the expected merged values, and a strict YAML 1.2 loader produces none of them because 1.2 dropped << from the core schema.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Block Scalars and Chomping Indicators

Every block-scalar variation in one file: literal and folded styles, all three chomping indicators, an explicit indentation indicator, a folded block with a paragraph break, and an embedded shell-shaped script whose own indentation must survive.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Norway Problem (Boolean Coercion)

The Norway problem in full: eleven bare words that a YAML 1.1 resolver turns into booleans, a matching quoted control group that survives, and a country-code list where position two silently becomes false. The definitive fixture for resolver-version behaviour.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Implicit Typing Traps

Twenty-two unquoted values whose type depends entirely on the resolver. The worst is the leading zero: 0755 is 493 under YAML 1.1 and 755 under YAML 1.2, so both resolvers return a number and they return different ones. Also covers base-60 times, a version that loses its trailing zero, an integer past IEEE-754 precision, dates, and .inf / .nan.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Duplicate Keys

Duplicate keys at three nesting levels, including a duplicated top-level sequence. The spec forbids them; most loaders keep the last silently, a few keep the first, and strict linters reject the document. The file publishes the last-wins answer.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML with TAB Indentation, Intentionally Invalid

An intentionally invalid YAML file indented with real TAB characters, which the spec forbids for indentation. The final key shows the legal case — a tab inside a quoted scalar — so a parser can be checked for rejecting one without rejecting the other.

File: YAML · YAML Edge Cases
Use case: Error handlingConfig parsing+1

YAML Multi-Document Stream

A five-document stream with explicit end markers, a comment-only document that loads as null, and a bare sequence as a whole document. The single-document API returns only the first, which is how multi-object manifests silently lose objects.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Null and Empty Values

Five spellings of null against the things routinely confused with it: empty strings, empty collections, and a key written with no value at all. Includes a sequence containing a hole, an empty string and two nulls in a row.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Quoting Styles and Escapes

All three scalar quoting styles side by side: plain scalars and what they cannot contain, single quotes where backslashes stay literal and '' means one quote, and double quotes as the only style that processes \t, \n and \uXXXX escapes.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Flow and Block Styles

Flow (JSON-like) and block collections expressing the same structures, nested inside one another in both directions, plus a flow mapping wrapped across lines and a line of strict JSON — which is valid YAML, and a useful check on a parser's JSON-subset claim.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Indentation Variants

The indentation styles that all parse identically and that formatters fight over: sequences flush with their key versus indented under it, two-space against four-space maps, and deliberately irregular but legal nesting. For testing formatters and idempotency.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Non-ASCII Keys and Values

Non-ASCII keys and values across Latin, Cyrillic, Arabic, CJK and emoji, plus a key containing a zero-width space and a value distinguishing a combining acute from the precomposed character. Written as UTF-8 with no BOM.

File: YAML · YAML Edge Cases · UTF-8, no BOM
Use case: Config parsingEncoding detection+1

YAML with CRLF Line Endings

A YAML file written with CRLF line endings, which the spec accepts as a line break. A parser that splits on \n alone leaves a stray carriage return at the end of every plain scalar, so "build" becomes "build\r" and equality checks quietly fail.

File: YAML · YAML Edge Cases · UTF-8, no BOM
Use case: Config parsingEncoding detection+1

YAML with a UTF-8 Byte Order Mark

A YAML file beginning with a UTF-8 byte order mark, which the spec permits at the start of a stream. A parser that does not strip it reads the first key as \ufeffname, so the lookup misses and the document appears to be missing its name field.

File: YAML · YAML Edge Cases · UTF-8 with BOM
Use case: Config parsingEncoding detection+1

YAML Bounded Anchor Reuse

Nested anchor reuse kept deliberately small: two anchors, six references, thirty-one expanded nodes. It is here to test alias resolution and expansion accounting on a safe input, and is explicitly not a billion-laughs expansion bomb.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Explicit and Local Tags

Explicit tags across the standard set — !!str, !!float, !!int, !!bool, !!null, !!binary, !!timestamp, !!omap, !!set — alongside two application-local ! tags. CI dialects use local tags in the wild, so a pipeline parser has to decide whether to reject, ignore, or resolve them.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Directives and Comments

A two-document stream where each document declares its own %YAML directive and the second adds a %TAG handle used by a local tag. Comments appear in every position they are legal, and every one of them is lost by a non-round-tripping loader.

File: YAML · YAML Edge Cases
Use case: Config parsingEncoding detection+1

YAML Unclosed Flow Collection, Intentionally Invalid

An intentionally invalid YAML file whose flow sequence is opened and never closed, so the parser consumes the rest of the document and fails at end of stream. A good error message names the opening bracket, not the last line, which is what this fixture measures.

File: YAML · YAML Edge Cases
Use case: Error handlingConfig parsing+1