Kubernetes CustomResourceDefinition with OpenAPI Schema
A CustomResourceDefinition carrying a deep structural OpenAPI v3 schema with a regex pattern, an enum, a default, and array minItems. Useful both as a CRD fixture and as a nested JSON-Schema-in-YAML validation target.
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: buildpipelines.example.invalid
spec:
group: example.invalid
scope: Namespaced
names:
plural: buildpipelines
singular: buildpipeline
kind: BuildPipeline
shortNames:
- bp
versions:
- name: v1alpha1
served: true
storage: true
subresources:
status: {}
schema:
openAPIV3Schema:
type: object
required:
- spec
properties:
spec:
type: object
required:
- stages
properties:
stages:
type: array
minItems: 1
items:
type: object
required:
- name
properties:
name:
type: string
pattern: "^[a-z][a-z0-9-]{0,30}$"
dependsOn:
type: array
items:
type: string
retries:
type: integer
minimum: 0
maximum: 5
default: 1Specifications
- Kind
- CustomResourceDefinition
- Group
- example.invalid
- Versions
- 1
- Schema Depth
- 6
- Has Pattern
- true
- Has Enum
- true
- Has Default
- true
Testing contract
Reference control- Scenario
- Extract and apply the structural schema embedded in a CustomResourceDefinition
- Expected result
- The schema validates a custom resource with at least one named stage and rejects a stage name that fails the ^[a-z][a-z0-9-]{0,30}$ pattern
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
“Kubernetes CustomResourceDefinition with OpenAPI Schema” is a deterministic Novus Examples fixture for Schema validation, JSON parsing, Config testing. JSON Schema documents describing a data shape — for testing validators and schema-aware tooling.
Documented properties for this file: YAML · 1,575 bytes. 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.
Code examples
import yaml # pip install pyyaml
with open("crd-buildpipeline.yaml") as f:
data = yaml.safe_load(f)
print(data)Related files
- jsonHelm values.schema.jsonThe values.schema.json that validates the paired Helm values files: a 2020-12 JSON Schema with $defs, $ref, enums, quantity patterns, and additionalProperties: false on nested objects. Validates the defaults and rejects a values file with an unknown image key.
- jsonTerraform Plan JSONA Terraform plan JSON document with create, update and delete changes, after_unknown markers, sensitivity annotations, and a configuration section. This is the artifact policy engines read before anything runs, which is why it sits with pipeline definitions rather than with run reports.
- jsonin-toto Layout (Supply-Chain Policy)The policy half of in-toto: a layout declaring which steps must run, which keys may sign them, and the MATCH/CREATE/DISALLOW artifact rules that bind each step's products to the next step's materials. 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.
- ymlGitHub 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.
- jsonApp Settings (JSON)JSON application settings for config-merge and validation tests.
- yamlAttestation 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.
Generated by generation/pipelines.py. Free for any use, no attribution required — license.