-
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
improve passing context #4774
improve passing context #4774
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4774 +/- ##
=======================================
Coverage 61.08% 61.08%
=======================================
Files 295 295
Lines 20660 20660
=======================================
Hits 12621 12621
Misses 7142 7142
Partials 897 897 |
eaa6886
to
ce92d38
Compare
f60ef7e
to
834e912
Compare
834e912
to
a4f985c
Compare
Let me move this one out of draft, but please have a close look to see if the approach makes sense. I recall I was fiddling a bit with passing the context with the combination of closures and call-sites of different parts of the 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.
I think there are still a few places this can be improved, especially on setting context in the dockerCLI.
dockerCli, err := command.NewDockerCli(command.WithBaseContext(ctx))
I can also move this PR forward if you'd like me to since I am working on adding more context to the docker client in moby and adding support in the CLI for it.
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
@thaJeztah can you TA(nother)L? |
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.
Leaving request changes for now; I don't think we should merge this for v26 since it's a breaking change to the plugin.Run
function.
6ae4186
to
0c8869f
Compare
cli-plugins/plugin/plugin.go
Outdated
otel.SetErrorHandler(debug.OTELErrorHandler) | ||
|
||
dockerCli, err := command.NewDockerCli() | ||
dockerCli, err := command.NewDockerCli(command.WithBaseContext(ctx)) |
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.
Do plugins add their own ctx to the dockerCli with the makeCmd
?
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.
compose seems to use whatever cobra's context is (https://github.com/docker/compose/blob/85567ae09246ea79191e35f060d230aa5b7c0e5b/cmd/compose/compose.go#L384)
buildx uses this func defined in buildkit though, but watch out since it already handles signals (https://github.com/docker/buildx/blob/a9575a872ab2018418e668649ed488090402a04a/commands/root.go#L35
https://github.com/moby/buildkit/blob/master/util/appcontext/appcontext.go)
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 see, yeah this will be breaking for plugins. I'll see what I can do to work around that.
but watch out since it already handles signals
that's fine, this PR doesn't do any signal handling here, but this is a good point and will work around this
@@ -352,7 +353,7 @@ func runDocker(ctx context.Context, dockerCli *command.DockerCli) error { | |||
// We've parsed global args already, so reset args to those | |||
// which remain. | |||
cmd.SetArgs(args) | |||
err = cmd.Execute() | |||
err = cmd.ExecuteContext(ctx) |
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.
take note, instead of passing ctx
to the root command through convoluted function calls I've cleaned it up a bit by instead passing context to cobra when we call ExecuteContext
. This should only affect the CLI and not any plugins that are run through the CLI.
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, yes, this was one of the things to look into!
(Still catching up on latest changes in this PR, but yes, this was one where my approach was probably not right)
cli/cobra.go
Outdated
@@ -23,8 +22,7 @@ import ( | |||
|
|||
// setupCommonRootCommand contains the setup common to | |||
// SetupRootCommand and SetupPluginRootCommand. | |||
func setupCommonRootCommand(ctx context.Context, rootCmd *cobra.Command) (*cliflags.ClientOptions, *cobra.Command) { | |||
rootCmd.SetContext(ctx) |
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.
removed this here since we can use the cobra ExecuteContext
instead. This prevents us from passing in ctx
to the plugins through RunPlugin
.
0aad14d
to
8278828
Compare
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
cmd/docker/docker.go
Outdated
err = cmd.Execute() | ||
err = cmd.ExecuteContext(ctx) | ||
if err != nil { | ||
return err |
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.
Did this get borked during a rebase? It's returning early, should be returning after hooks get called I think
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 true! will fix
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! Should it still handle context errors early though? (cancelled context? or timeout?) I guess in that case the hooks should not be called?
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 think it's fine to do it regardless in any case here? The plugin can decide if it wants to print something or not. Even if it's cancelled, a hook might want to add some hint/explain something.
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.
Yeah, not sure if a cancelled context should still be used; isn't context cancelation basically; "cancel my request" (on the first possible occasion) ? In some cases that may mean some work is needed to complete the transaction (flush to disk, e.g.) but calling hooks (and execute other binaries) feels like that should not be part 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.
that's valid, sure. @Benehiko wdyt
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.
mmh i'm not sure if hooks should be called after a cancellation, it'd feel wrong to me
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 don't have too much opinion on this either way. We currently execute the hooks even when the cobra Execute
function returns an error (which is a similar thing to context cancellation).
Cancelling the context early will still execute the cobra commands, but the commands checking for context cancellation will just return (with maybe an error?).
See below an example of a cobra command not acting on the context cancellation. Even if it was acting and returning an error it will still execute.
package main
import (
"context"
"fmt"
"github.com/spf13/cobra"
)
func main() {
ctx, cancel := context.WithCancel(context.Background())
rootCmd := &cobra.Command{
Use: "",
RunE: func(cmd *cobra.Command, args []string) error {
cmd.Help()
fmt.Printf("Cobra command ctx: %v\n", cmd.Context().Err())
return nil
},
}
cancel()
fmt.Printf("Before Cobra ctx: %v\n", ctx.Err())
err := rootCmd.ExecuteContext(ctx)
fmt.Printf("%v\n", err)
}
⋊> ~/G/test-cobra go run . 09:14:06
Before Cobra ctx: context canceled
Usage:
[flags]
Flags:
-h, --help help for this command
Cobra command ctx: context canceled
<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.
See here what the code currently looks like on the master branch
https://github.com/docker/cli/blob/master/cmd/docker/docker.go#L355-L367
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
Ah, one more thing, can you please add the changelog description with highlighting the API change? EDIT: Sorry, I confused PRs 🙈 There was no API change in the end here (we didn't alter the |
Explicitly create the context and set it on the CLI, instead of depending on NewDockerCli() to instance a default context. Co-authored-by: Sebastiaan van Stijn <github@gone.nl> Co-authored-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com> Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
@vvoland You had the PR right, I just reverted those changes in the PR and squashed the commits |
Relates to OTEL changes and graceful exit changes
See below PRs
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)