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.
# Compose Specification shape: no top-level `version:` key, which the spec deprecated and modern
# Compose warns about. A parser written against the older schema often *requires* it, so this
# fixture is the one that separates the two generations of tooling.
name: orders-stack
services:
api:
image: registry.example.invalid/example-org/orders:1.4.0
restart: unless-stopped
ports:
- "8080:8080"
environment:
LOG_LEVEL: info
CACHE_URL: redis-compatible://cache:6379
depends_on:
cache:
condition: service_healthy
migrate:
condition: service_completed_successfully
healthcheck:
test: ["CMD", "example-healthcheck", "--port", "8080"]
interval: 10s
timeout: 2s
retries: 3
start_period: 20s
networks:
- backend
deploy:
resources:
limits:
cpus: "0.50"
memory: 512M
cache:
image: registry.example.invalid/example-org/cache:2.1.0
healthcheck:
test: ["CMD", "example-ping"]
interval: 5s
retries: 5
volumes:
- cache-data:/data
networks:
- backend
migrate:
image: registry.example.invalid/example-org/orders:1.4.0
command: ["migrate", "--to", "latest"]
restart: "no"
networks:
- backendSpecifications
- Schema
- Compose Specification
- Has Version Key
- false
- Services
- 3
- Healthchecks
- 2
- Depends On Conditions
- 2
- Networks
- 1
- Volumes
- 1
Testing contract
Expected to pass- Scenario
- Parse a Compose file that omits the deprecated top-level version key
- Expected result
- Three services resolve and the api service reports two conditional dependencies: service_healthy on cache and service_completed_successfully on migrate
What is a .yaml file?
YAML (YAML Ain't Markup Language) is a human-readable data-serialization format using indentation, key-value pairs, and lists, and is a superset of JSON. It supports comments, anchors, and multiple documents per file, favoring readability for configuration. Its indentation sensitivity makes it error-prone to hand-edit.
How to use this file
Use an example YAML file to test config parsers, indentation and anchor handling, multi-document streams, and safe-loading to avoid arbitrary object construction.
How to use this file for testing
“Docker Compose Specification (No version Key)” is a deterministic Novus Examples fixture for Config testing, Config parsing, Editor testing. TOML, INI, YAML, .env, and dotfile configuration samples with nested sections and typed values — for testing config parsers, loaders, and environment tooling.
Documented properties for this file: schema: Compose Specification. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Pipeline and infrastructure fixtures are inert configuration: steps reference fictional images and scripts, and nothing here executes. Run your linter, schema validator, migrator, or policy engine against them, and expect the deprecated-syntax and intentionally invalid variants to be rejected.
Point your config loader at the file and assert it reads the documented sections and typed values, including any deliberately-tricky nesting or comments.
Code examples
import yaml # pip install pyyaml
with open("compose-spec-modern.yaml") as f:
data = yaml.safe_load(f)
print(data)Related files
- yamlDocker Compose ProfilesFive 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.
- yamlArgo CD Application with Sync PolicyAn 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.
- yamlArgo CronWorkflow ScheduleAn 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.
- ymlAzure Pipelines Matrix StrategyAzure'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.
- ymlAzure Pipelines Stages and Deployment JobA 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.
- ymlAzure Pipelines Steps and TriggersThe 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.
Generated by generation/pipelines.py. Free for any use, no attribution required — license.