Files
moby/api
Sebastiaan van Stijn f8d3c4e4a7 api/types/image: InspectResponse: remove deprecated Parent, DockerVersion
The InspectResponse type contains various fields that are deprecated
and removed from current API versions, but that were kept for the API
server to produce the fields when downgrading to older API versions.

- The `Parent` field is only used for the legacy builder, and only set for
  images that are built locally (i.e., not persisted when pulling an image).
- The `DockerVersion` field is only set when building images with the legacy
  builder, and empty in most cases.

Both fields were implicitly deprecated with the deprecation of the legacy
builder, and deprecated for the API in [moby@bd8a99b], which was backported
to the 28.x release.

This patch:

- Removes the deprecated fields from the `InspectResposne` struct; this
  means that [`client.ImageInspect`] won't unmarshal those fields, but
  the [`docker image inspect`] CLI command defaults to printing the raw
  output as returned by the API, so can continue to show any field returned
  in the API response. As a side-note; we should change the CLI to default
  to show the unmarshalled response, and introduce a `--format=jsonraw`
  (or `--raw`) option to make printing the raw response opt-in.
- Updates the API server to backfill the fields if they are set.

[moby@bd8a99b]: bd8a99b400
[`client.ImageInspect`]: f739c61c69/client/image_inspect.go (L14-L64)
[`docker image inspect`]: 74e3520724/cli/command/image/inspect.go (L59-L81)

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2025-10-07 13:31:17 +02:00
..
2025-09-04 22:54:01 -07:00
2025-08-08 01:16:30 +02:00

Engine API

PkgGoDev GitHub License Go Report Card OpenSSF Scorecard OpenSSF Best Practices

The Engine API is an HTTP API used by the command-line client to communicate with the daemon. It can also be used by third-party software to control the daemon.

It consists of various components in this repository:

  • api/swagger.yaml A Swagger definition of the API.
  • api/types/ Types shared by both the client and server, representing various objects, options, responses, etc. Most are written manually, but some are automatically generated from the Swagger definition. See #27919 for progress on this.
  • client/ The Go client used by the command-line client. It can also be used by third-party Go programs.
  • daemon/ The daemon, which serves the API.

Swagger definition

The API is defined by the Swagger definition in api/swagger.yaml. This definition can be used to:

  1. Automatically generate documentation.
  2. Automatically generate the Go server and client. (A work-in-progress.)
  3. Provide a machine readable version of the API for introspecting what it can do, automatically generating clients for other languages, etc.

Updating the API documentation

The API documentation is generated entirely from api/swagger.yaml. If you make updates to the API, edit this file to represent the change in the documentation. Documentation for each API version can be found in the docs directory, which also provides a CHANGELOG.md.

The file is split into two main sections:

  • definitions, which defines re-usable objects used in requests and responses
  • paths, which defines the API endpoints (and some inline objects which don't need to be reusable)

To make an edit, first look for the endpoint you want to edit under paths, then make the required edits. Endpoints may reference reusable objects with $ref, which can be found in the definitions section.

There is hopefully enough example material in the file for you to copy a similar pattern from elsewhere in the file (e.g. adding new fields or endpoints), but for the full reference, see the Swagger specification.

swagger.yaml is validated by hack/validate/swagger to ensure it is a valid Swagger definition. This is useful when making edits to ensure you are doing the right thing.

Viewing the API documentation

When you make edits to swagger.yaml, you may want to check the generated API documentation to ensure it renders correctly.

Run make swagger-docs and a preview will be running at http://localhost:9000. Some of the styling may be incorrect, but you'll be able to ensure that it is generating the correct documentation.

The production documentation is generated by vendoring swagger.yaml into docker/docs.