-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
delegate build to buildx bake #11484
Conversation
08f256f
to
a92f4ee
Compare
pkg/compose/build_buildkit.go
Outdated
ID: "==> ==>", | ||
Status: progress.Done, | ||
Text: fmt.Sprintf(`naming to %s`, options.Tags[0]), | ||
cmd := exec.CommandContext(ctx, "docker", "buildx", "bake", "--file", "-", "--progress", "rawjson", "--metadata-file", metadata.Name()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should call buildx in standalone mode to reduce overhead implied by docker
command (and in particular docker proxy in DD).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also has implications wrt signal handling, CLI plugin management, etc. In this case we'd have CLI binary
-> Compose plugin binary
-> CLI binary
-> Buildx plugin binary
AND between the CLI and Compose and then between the 2nd CLI process and Buildx the CLI would be setting up a socket for plugin communication, etc. Need to think about what the tradeoffs are there/whether we should and what we can do on the CLI side to make this as painless as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes this I already identified, marked this as a Draft to avoid any confusion: there's a bunch of things missing here :)
8793d51
to
0c01a6f
Compare
pkg/compose/build_buildkit.go
Outdated
if err != nil { | ||
return "", err | ||
} | ||
cmd := exec.CommandContext(ctx, buildx.Path, "buildx", "bake", "--file", "-", "--progress", "rawjson", "--metadata-file", metadata.Name()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀
cmd := exec.CommandContext(ctx, buildx.Path, "buildx", "bake", "--file", "-", "--progress", "rawjson", "--metadata-file", metadata.Name()) | |
cmd := exec.CommandContext(ctx, buildx.Path, "bake", "--file", "-", "--progress", "rawjson", "--metadata-file", metadata.Name()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as we propagate os.Env, DOCKER_CLI_PLUGIN_ORIGINAL_CLI_COMMAND
is set and buildx get confused it's not actually running standalone. Need to exclude this variable to get buildx run standalone
0c01a6f
to
f3104d0
Compare
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
f3104d0
to
cdb5fb7
Compare
would compose send to bake |
It could (this PR is 100% experimental) but AFAICT |
It could be quite welcomed, but, when it comes to |
Already supported if you run |
Did the stale timer expire? |
revisited as #12300 |
What I did
Use buildx raw json output (moby/buildkit#4113) so we can implement build as an external command.
Allows user to upgrade buildx and benefits new features/bug fixes without having to wait for compose to bump dependencies
Still relies on buildkit's progress UI, but we technically could redesign the build progress display by processing solver status on our own. If we do, we could fully remove dependency on buildx/buildkit
note: due to docker/buildx#2252, json parsing error must be ignored :'(
(not mandatory) A picture of a cute animal, if possible in relation to what you did