Open mejedi opened 5 months ago
Compose extensibility by add-on binaries has been considered and experimented internally without a clear conclusion regarding benefits and impacts on Compose portability and ecosystem. I don't think such a feature will take place short terms. Tagged for "future release" assuming at some point we will run a brainstorming session to define next generation compose architecture
Description
Recently several language-specific build tools emerged. These tools produce a container image without having to write a Dockerfile. Golang has ko-build. Java got something as well.
(Besides convenience, a strong selling point is efficiency. For instance, ko produces multi-arch images by leveraging cross-compilation support in Golang toolchain. It also takes advantage of different caches in the host, such as module and build caches. Golang workspaces work seamlessly with ko. Finally, if dependencies in private repositories are required, enabling access in a Dockerfile is an annoyance. Eliminated with ko.)
It would be nice if
build:
section indocker-compose.yaml
was extended to support these language-specific builders.One way to do it would be piggy-backing on existing
build: URL
syntax. If a schema is not http(s), like e.g.ko://example.org/foo/bar
, look fordocker-compose-build-<SCHEMA>
inPATH
. Passexample.org/foo/bar
as an argument todocker-compose-build-ko
and extract image ID from command's stdout.