-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
make runAttach public and allow passing context #4637
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #4637 +/- ##
=======================================
Coverage 59.74% 59.74%
=======================================
Files 288 288
Lines 24849 24849
=======================================
Hits 14846 14846
Misses 9117 9117
Partials 886 886 |
cli/command/container/attach.go
Outdated
func RunAttach(dockerCli command.Cli, opts *attachOptions) error { | ||
return RunAttachWithContext(context.Background(), dockerCli, opts) | ||
} | ||
|
||
func RunAttachWithContext(ctx context.Context, dockerCli command.Cli, opts *attachOptions) 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.
Perhaps we only need one; we can move the context.Background()
to NewAttachCommand
, and make the (now exported) RunAttach
accept a context.
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'm also looking if we can change this function to accept just the apiClient
, but looks like that may need more work.
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! Actually, I don't think just exporting this will help you, because attachOptions
is not exported, so we may need a function that takes container.AttachOptions
instead (but that means we need some way to set all the required options in it, which looks to be somewhat involved still.
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 tried to limit changes to the strict minimum :)
I wonder why we use a context.Background()
here and not the cobra cmd.Context()
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.
change this function to accept just the apiClient
this indeed would have much more impacts, as dockerCli
is passed to a bunch of public functions, whenever only APIClient or Streams is actually required. This would require a more significant deprecation/newFunc dance :P
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.
because attachOptions is not exported
I've been to fast here indeed :)
also exported AttachOptions (same way I did for ExecOptions
on 2d26839)
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 why we use a context.Background() here and not the cobra cmd.Context()
My best guess; because it originally wasn't there when this code was written (it was added in 2020, and likely code wasn't updated at the time)
4f85512
to
667665c
Compare
cli/command/container/attach.go
Outdated
// RunAttach executes an `attach` command | ||
func RunAttach(dockerCli command.Cli, opts *AttachOptions) error { | ||
return RunAttachWithContext(context.Background(), dockerCli, opts) | ||
} | ||
|
||
// RunAttachWithContext executes an `attach` command | ||
func RunAttachWithContext(ctx context.Context, dockerCli command.Cli, opts *AttachOptions) 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.
Given that runAttach
was un-exported before this, I think it's fine to only have one function (RunAttach
) and have that accept a context; we can probably create and pass the context in NewAttachCommand
/ RunE
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.
right, just wanted to be homogeneous with RunExecWithContext
in method naming
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.
Looking at RunExec
, I see it was exported for compose as well;
These functions were never intended to be exported "as-is", and I'd be ok with changing the signature of RunExec
to accept a context (we want to add contexts to these as well for OTEL integration; see #4556
667665c
to
71b3c52
Compare
For future reference; we need to have a look at these. The current situation is far from ideal; there's too much logic in the CLI that is not always trivial to replicate. BUT those implementations are written very specifically for the While exporting relieves some of the pain in compose to allow re-using the logic, it also means that some of these now become a public API, which can complicate maintenance, as we now have to take potential external consumers into account. That's "mostly" fine if "external" means "compose" (we can co-ordinate if we make breaking changes), but may catch "other" consumers off-guard. Longer term, we SHOULD have more of these functions exported (and move them to the Perhaps we should add a warning to these function's GoDoc to outline that while they're exported, they are not considered a stable API (as in: signatures may change); “exported for internal use, don’t depend on this”. I’m also looking a bit if we can reduce the blast-area on these changes. Most notably the Looking at that, there’s two options missing;
I'm "ok" with these changes, but we should look at some of those follow-ups (at least the "document as unstable") before we've dug ourselves in a hole that we can't get out of. |
Trying to make "runAttach" not depend on attachOptions, and to see if we can make it accept container.AttachOptions instead relates to docker#4637 Signed-off-by: Sebastiaan van Stijn <[email protected]>
cli/command/container/attach.go
Outdated
func runAttach(dockerCli command.Cli, opts *attachOptions) error { | ||
ctx := context.Background() | ||
// RunAttach executes an `attach` command | ||
func RunAttach(ctx context.Context, dockerCli command.Cli, opts *AttachOptions) 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.
I was exploring some options in #4643, and all those are probably out of scope for this PR, but perhaps if would make sense to include one part of that PR, and to pass containerID
as separate argument, instead of stuffing it into AttachOptions
. Thinking here that containerID
(/name) is a required argument, whereas (most? all?) options should ideally be optional.
71b3c52
to
6f55d47
Compare
@ndeloof looks like a test needs to be updated because the signature changed; otherwise I think we should be good to go (baring future work / follow-ups to possibly improve some of this) |
Signed-off-by: Nicolas De Loof <[email protected]>
6f55d47
to
a4abe42
Compare
Signed-off-by: Nicolas De Loof <[email protected]>
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.
LGTM
thanks! I hate it ❤️
Trying to make "runAttach" not depend on attachOptions, and to see if we can make it accept container.AttachOptions instead relates to docker#4637 Signed-off-by: Sebastiaan van Stijn <[email protected]>
Trying to make "runAttach" not depend on attachOptions, and to see if we can make it accept container.AttachOptions instead relates to docker#4637 Signed-off-by: Sebastiaan van Stijn <[email protected]>
Trying to make "runAttach" not depend on attachOptions, and to see if we can make it accept container.AttachOptions instead relates to docker#4637 Signed-off-by: Sebastiaan van Stijn <[email protected]>
Trying to make "runAttach" not depend on attachOptions, and to see if we can make it accept container.AttachOptions instead relates to docker#4637 Signed-off-by: Sebastiaan van Stijn <[email protected]>
- What I did
make
runAttach
a public method to be used by docker compose (enforce alignment and avoid code duplication)introduce
runXXWithContext
to pass current context- How I did it
- How to verify it
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)