schema: no constraint requires image, build or provider, but the loader rejects a service with none of them #933

Activity

1. simin-yuan commented on Sep 29, 2026

   

   simin-yuan

   on Sep 29, 2026

   Author

   More actions

   Follow-up: I picked up the two branches I had left unverified in the report, and tested both against the schema as vendored in this repository.

   • provider is expressible the same way as the others. It is a declared property of $defs/service (line 926 of schema/compose-spec.json), with required: ["type"]. So a provider-only service is accepted by the schema today, and that anyOf branch closes a real case rather than a hypothetical one. Tested: services: {app: {provider: {type: docker}}} validates against the unmodified schema.
   • $defs/service is an object carrying allOf over container_spec plus workload_spec, with a sibling properties block. An anyOf next to that allOf applies as intended.

   Patch tested here against schema/compose-spec.json at blob e4e473bbca37c1fdbd7cfe957644c615b04f284b (main, 2026-09-29), inserted into $defs/service as a sibling of allOf:

   "anyOf": [
     { "required": ["image"] },
     { "required": ["build"] },
     { "required": ["provider"] },
     { "required": ["extends"] }
   ]

   extends is not padding. It is resolved before checkConsistency runs, so a service with only extends is legal whenever the base it inherits from supplies one of the other three. Dropping that branch would reject files the loader accepts, which is a worse outcome than the hole being fixed. A service whose base supplies nothing still fails at load time, so this closes the editor-side hole, not every input the loader rejects.

   Validation with check-jsonschema 0.38.2 (YAML input, so no conversion step):

   input	schema as published	with the patch
   services: {app: {container_name: app, restart: always}}	ok	rejected
   image only	ok	ok
   build only	ok	ok
   provider only	ok	ok
   extends only	ok	ok

   Regression run: all 42 YAML files under loader/testdata/ at main, validated twice, once with the unmodified schema and once with the patched one. 39 accepted by both, 3 rejected by both (they are fragments, not standalone documents), 0 verdict changes.

   Second gap in the same pair, same treatment. loader/validate.go lines 242-246:

   if secret.External { continue }
   if secret.File == "" && secret.Environment == "" { ... error ... }

   $defs/secret carries no required at all, so secrets: {s: {}} and secrets: {s: {name: custom}} validate while the loader rejects both. Tested form:

   "anyOf": [
     { "required": ["file"] },
     { "required": ["environment"] },
     { "required": ["external"], "properties": { "external": { "const": true } } }
   ]

   secrets: {s: {}} is ok before and rejected after; file, environment and external: true all validate both ways. The const is deliberate: external: false falls through the continue and still needs a source.

   What I did not do, so that nobody reads more into the tables than they say:

   • No Go test suite was run. schema/schema_test.go and the loader tests were not executed; the regression evidence above is schema against schema over YAML fixtures.
   • Explicit nulls: build: with no value parses to nil in Go and the loader rejects it, while {"required": ["build"]} accepts it. Closing that would need something like {"properties": {"build": {"not": {"type": "null"}}}, "required": ["build"]}, which I did not test.
   • I did not check whether a consumer relies on the schema accepting a sourceless service on purpose. If one does, this is an entry in the known-gaps list rather than a schema change.
   • schema/compose-spec.json here is a copy of the upstream file, so this may need to land in compose-spec/compose-spec first.