Build platforms

With the arrival of Arm on developer laptops and in data centers, developers are being pushed into a multi architecture world. Compose services have a platform property of type string which is used to determine what the pulled or built image's platform should be.

This works for local development or deployment as users only need a single architecture at a time. When publishing images to a container registry, users may want to build and push the images for multiple platforms.

Question:
Should the build section have a platform property of type list of strings? If so, how does this relate to the service platform?

Proposal:
Add a platform string list property to build that is respected only when pushing images, doing an implicit build if needed. This will allow developers to have a quick development cycle (only using one architecture) but allow them to publish their images with multi architecture support.

Other properties

Investigating further, there may be other build properties that we would like to add. The current set of build properties are:

"context": {"type": "string"},
"dockerfile": {"type": "string"},
"args": {"$ref": "#/definitions/list_or_dict"},
"labels": {"$ref": "#/definitions/list_or_dict"},
"cache_from": {"$ref": "#/definitions/list_of_strings"},
"network": {"type": "string"},
"target": {"type": "string"},
"shm_size": {"type": ["integer", "string"]},
"extra_hosts": {"$ref": "#/definitions/list_or_dict"},
"isolation": {"type": "string"}

Docker buildx includes the following interesting flags that are currently not exposed in the Compose format:

      --allow strings            Allow extra privileged entitlement, e.g. network.host, security.insecure
      --builder string           Override the configured builder instance
      --cache-from stringArray   External cache sources (eg. user/app:cache, type=local,src=path/to/dir)
      --cache-to stringArray     Cache export destinations (eg. user/app:cache, type=local,dest=path/to/dir)
      --load                     Shorthand for --output=type=docker
      --no-cache                 Do not use cache when building the image
  -o, --output stringArray       Output destination (format: type=local,dest=path)
      --platform stringArray     Set target platform for build
      --secret stringArray       Secret file to expose to the build: id=mysecret,src=/local/secret
      --ssh stringArray          SSH agent socket or keys to expose to the build (format: default|<id>[=<socket>|<key>[,<key>]])

Question:
Should we add any of these properties?

Proposal:
There are some options taht would make sense to add now. Specifically:

• cache-to: Logical given that we have cache-from already.
• no-cache: Logical given the ability to specify a cache.
• platform: As described above.
• secret: It's a common issue that people do not have an easy way to attach secrets in a way that they are not built into the image.

Some require more consideration as they're either very Docker specific or might be too niche:

• allow
• builder
• load
• output
• ssh