-
Notifications
You must be signed in to change notification settings - Fork 617
Consistent timeout parameter #3159
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
Changes from all commits
b1c7535
8a5814e
7424d39
8397072
f56bc0d
8e99912
bf77130
0abd361
a972eb1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,6 +4,7 @@ import ( | |
| "bytes" | ||
| "context" | ||
| "fmt" | ||
| "time" | ||
|
|
||
| "github.com/docker/buildx/builder" | ||
| "github.com/docker/buildx/driver" | ||
|
|
@@ -27,6 +28,7 @@ type createOptions struct { | |
| buildkitdFlags string | ||
| buildkitdConfigFile string | ||
| bootstrap bool | ||
| timeout time.Duration | ||
| // upgrade bool // perform upgrade of the driver | ||
| } | ||
|
|
||
|
|
@@ -61,6 +63,7 @@ func runCreate(ctx context.Context, dockerCli command.Cli, in createOptions, arg | |
| Use: in.use, | ||
| Endpoint: ep, | ||
| Append: in.actionAppend, | ||
| Timeout: in.timeout, | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it intentional that this is passed as a value rather than added to
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Addressing how the timeout is used: Addressing where the Timeout comes from: As for passing the timeout as a field in CreateOpts vs adding it to ctx, I don't know for sure why it was done that way, but I'd guess because nothing else in runCreate modifies the ctx. Not being much of a go user, I will take your word that the Create call can take more time than timeout but the slow part of runCreate seems bounded by the timeout just like before?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd just add it to the context as with the other commands if we don't know the reason why this one should be different.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, I'm a bit confused what you mean. Upon closer inspection the rm, ls, inspect, and create commands all do it this way, vs the build command that's different. The build command gets the timeout from the control.ControlOptions inclusion in the buildOptions struct, but doesn't seem to use it anywhere, possibly because builds tend to take absolute ages? As a non go user what does, "add it to the context" mean, and in what way is that different between the create command and the rm, ls, or inspect commands? |
||
| }) | ||
| if err != nil { | ||
| return err | ||
|
|
@@ -80,7 +83,7 @@ func runCreate(ctx context.Context, dockerCli command.Cli, in createOptions, arg | |
| return nil | ||
| } | ||
|
|
||
| func createCmd(dockerCli command.Cli) *cobra.Command { | ||
| func createCmd(dockerCli command.Cli, rootOpts *rootOptions) *cobra.Command { | ||
| var options createOptions | ||
|
|
||
| var drivers bytes.Buffer | ||
|
|
@@ -96,6 +99,7 @@ func createCmd(dockerCli command.Cli) *cobra.Command { | |
| Short: "Create a new builder instance", | ||
| Args: cli.RequiresMaxArgs(1), | ||
| RunE: func(cmd *cobra.Command, args []string) error { | ||
| options.timeout = rootOpts.timeout | ||
| return runCreate(cmd.Context(), dockerCli, options, args) | ||
| }, | ||
| ValidArgsFunction: completion.Disable, | ||
|
|
||
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.
If the driver timeout is still constant 120s and can't be changed, wouldn't it be safer if this would be added in the
driverpkg. Atm I think you could still theoretically call driver pkg forgetting to pass inInitConfig.Timeoutand then possibly bad things can happen as it doesn't seem to be validated.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 added a check in GetDriver that the Timeout is set to something > 0.