You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 in docker-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 for docker-compose-build-<SCHEMA> in PATH. Pass example.org/foo/bar as an argument to docker-compose-build-ko and extract image ID from command's stdout.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: