Add ability to specify the means of building an image for specific service(s)

[Karol Zadora-Przylecki]

Rationale

.NET SDK has now the ability to create and publish container images directly from .NET applications, without having to author, and maintain, a separate Dockerfile. It would be very convenient for .NET developers if Docker Compose had the ability to leverage this capability directly from Compose files.

Option 1: add ability to specify per-service image build command

Add a property to the build object of the service object that specifies what shell command to run if the image for the service is not present in the image store (before attempting to pull the image). For example

services:
  myapp:
    image: myapp:1.2.3
    build:
      image-build-command: dotnet publish --os linux --arch x64 /t:PublishContainer -c Release

This is similar to what @ndelof proposed here except that instead of specifying a BuildX builder name, the property contains a shell command that will be used to build the image.

Option 2: add ability to specify a name of BuildX builder that will be used to build service image

This is essentially the same as @ndelof proposed.

This proposal is different from PR to add --builder option to 'compose build' command in the sense that the builder is overridden per-service.

Why option 1 is preferred

The global option requires the builder to be able to build images for all services in the Compose workload, which is much more responsibility than what is strictly necessary to satisfy the rationale above if a Compose file contains non-.NET services (or if some services go beyond what .NET SDK can do and require a Dockerfile). Having a mix of services written in .NET and non-.NET languages in a Compose file is very common.

Option 2 also requires the user to set up the builder that "knows" about .NET SDK image build, so it is more difficult to use than just specifying an image build command.

@baronfel @hyu FYI