-
Notifications
You must be signed in to change notification settings - Fork 485
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
Add dial-stdio command #2112
Add dial-stdio command #2112
Conversation
} | ||
defer conn.Close() | ||
|
||
go func() { |
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.
Could we extract the logic for dial-stdio in buildkit into a reusable function so we could just call that here after getting the conn
? Ideally, we wouldn't end up with diverging implementations in buildctl/buildx (e.g. that would make it a pain to fix bugs in the future, etc).
We're also having the same thing in dagger, where we need dial-stdio
for the connhelper, but don't really want to ship all of buildctl
, so it would be cool to have just one implementation to call instead of needing to extract the relevant code.
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.
One implementation of what exactly?
the main part of this is just wiring up copy operations.
I'm not sure its worth sharing an implementation of that?
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.
Ah, I think I'm just confused by the differences in handling CloseRead
/CloseWrite
here versus in buildctl. Given that they seem to be doing the same thing, I'm not quite sure I understand why the code is so different.
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.
@AkihiroSuda I'm curious on this case where its wrapping with a nop-closer.https://github.com/moby/buildkit/blame/5ae9b23c40a926615b6c3cc1da3f5457d2f61fd4/cmd/buildctl/dialstdio.go#L35
I don't think we necessarily need the stream to handle a half-close here, just that it s a little cleaner in terms of the connection semantics (hence why its implemented here).
Other than that I think the implementation is pretty much the same, just this is taking advantage of errgroup and buildctl is basically doing its own hand-rolled equivalent.
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.
From my memory, tty stuff didn't work correctly without handling half-close there
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 was trying to test for using tty as stdin/stdout but this broke http2.
Not sure how to check for this.
Fundamentally though, the only real change as compared to buildctl would be to not fallback to Close
on when CloseRead
is not implemented.
78aac86
to
ea99e40
Compare
|
||
|
||
<!---MARKER_GEN_END--> | ||
|
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.
Let's add a bit more description/usage here. It isn't entirely obvious for new user what "dial stdio" means.
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.
Added extra docs.
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.
Not sure what changed for this
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 wrote stuff... apparently I did not commit it somehow.
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.
Pushed up again.
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.
Oh I know what happened... I did docs the wrong way.
dd3ca7c
to
94f5985
Compare
9b657e9
to
0c5390f
Compare
docs/reference/buildx_dial-stdio.md
Outdated
|
||
## Description | ||
|
||
dial-stdio uses the stdin and stoud streams of the command to proxy to the configured builder instance. |
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.
stdout
docs/reference/buildx_dial-stdio.md
Outdated
# docker buildx dial-stdio | ||
|
||
<!---MARKER_GEN_START--> | ||
Dial stdio |
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.
"Proxy current stdio streams to builder instance"
docs/reference/buildx_dial-stdio.md
Outdated
## Description | ||
|
||
dial-stdio uses the stdin and stoud streams of the command to proxy to the configured builder instance. | ||
It is not intended to be used by humans, but rather by other tools that want to interact with the builder instance API. |
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.
"builder instance API." -> "builder instance via BuildKit API"
docs/reference/buildx_dial-stdio.md
Outdated
}() | ||
|
||
client.New(ctx, "", client.WithContextDialer(func(ctx context.Context, s string) (net.Conn, error) { | ||
return c2, nil |
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.
Why use static instance here? I think it should invoke new command when dialer gets called.
func dial(...) (net.Conn, error) {
_ = exec.Command()
...
}
client.New(ctx, "", client.WithContextDialer(dial))
docs/reference/buildx_dial-stdio.md
Outdated
cmd.Stdin = c1 | ||
cmd.Stdout = c1 | ||
|
||
if err := cmd.Start() { |
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.
err := cmd.Start(); err != nil
docs/reference/buildx_dial-stdio.md
Outdated
|
||
```go | ||
|
||
client.New(ctx, "", client.WithContextDialer(func(ctx context.Context, s string) (net.Conn, error) { |
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.
nit: remove the parameters variable names if they are unused
This allows the buildx CLI to act a proxy to the configured instance. It allows external code to use buildx itself as a driver for connecting to buildkitd instances. Instance and node selection should follow the same semantics as as `buildx build`, including taking into account the `BUILDX_BUILDER` env var and the `--builder` global flag. Signed-off-by: Brian Goff <[email protected]>
This allows the buildx CLI to act a proxy to the configured instance. It allows external code to use buildx itself as a driver for connecting to buildkitd instances.
Instance and node selection should follow the same semantics as as
buildx build
, including taking into account theBUILDX_BUILDER
env var and the--builder
global flag.